Aside from my
general distaste of the double-encoding, it doesn't
handle the case of manual input: someone who types
into their URL bar shouldn't
end up at [[AT]].
If you ask me, they should.
People who don't care about the
details of HTML/HTTP/etc. will either follow links or type "AT&T"
into the search box, and all is well. If they want to type in
URLs, then they have already committed themselves to knowing
about the quirks of URLs.
I agree, which is why I disagree with the previous statement.
One of those quirks is that the URL
http://...AT&T is badly formed, and the browser is allowed to
interpret it in more than one way. It might choose to interpret it
as "fetch the page http://...AT" and pass it the query string "T".
Untrue. The ampersand is not reserved in URL path sections (though it is
in the query string) and is allowed as a legitimate path character; see
RFC 2396, section 3.3. When we use /wiki/Title URLs, we're putting the
title in a _path_, not a query string, and we must treat it as such.
Further, the query string can never be delimited by an ampersand, only
by a question mark.
URLs are code--URLs are not user interface elements.
If people who
choose to use URLs have to contend with their nuances as code,
I agree, which is why we should treat them according to the standards!
Now, all that said, I understand that the web rose so
we never had a chance to replace URLs with something usable, so
many users are forced to use them when they never should have been.
So I'm not opposed to making them easier sometimes. Let's make
them as simple as possible /but no simpler/. If we have to muck
with ampersands a bit just as we convert spaces to underscores,
then that's what we'll have to do.
BTW, would you mind putting source like that on the
in /usr/local/src? That's where I've got all the post-install
stuff including Apache, MySQL, etc.
Done, see /usr/local/src/ampersand.diff
-- brion vibber (brion @ pobox.com