Webmaster Forum / HTML, CSS, Scripts / CSS / August 2005

I'm not sure what potential problem you're meaning to rule out here,
but no, technically there isn't a problem at all - the only problem is
incomprehension by some HTML authors.  :-}

The submitted data isn't HTML at all, right; but if a *precomposed*
URL is used, then the way to use it in the source HTML is as the value
of an attribute (href="..." for a link, src="..." for an image, etc.).

And in forming the value of that attribute, if there's a "&" in the
URL, then it has to be expressed in &-notation (& or & - or
& if you feel you must) in the HTML attribute value.  

When HTML parses that & in the attribute value in the HTML source,
it'll leave just the "&" character itself to be used in the target
URL.  But you'd understood that already, right?

Nothing special, in other words - the same rule that applies to /all/
HTML attribute values which happen to have an ampersand in them (an
image whose alt text was coded as alt="Mom&Pop" would trigger just
such a validation error, too, and would need to be corrected to
alt="Mom&Pop" or equivalent).

Whereas, if the alternative semicolon is used for precomposed URLs, as
recommended in the HTML specifications, no such fiddling and bloat is
necessary.

It's perfectly OK to implement the server-side process to treat both
the "&" and the ";" as delimiters, since, if either or both of these
characters are meant to be interpreted as data rather than as
delimiters, the rules call for them to be sent in %xx-encoded format,
not as bare characters.  So the same server-side parser can be used,
regardless of which kind of submission is being sent.  

As I said, the respected Perl module CGI.pm parses both variants:
there's a switch to determine whether its *generated HTML* will use
semicolon (the default) or ampersand (on request), but that switch
changes only its generated HTML: it doesn't change CGI.pm's parsing of
submitted forms data at all - that code respects both of them as
delimiters, all the time.

h t h