Re: validator bug ?

At 09:24 26-01-00 , Braverman, David wrote:
>> "We recommend that HTTP server implementors, and 
>> in particular, CGI implementors support the use of ";" 
>> in place of "&" to save authors the trouble of escaping 
>> "&" characters in this manner."

>Ah, so if your server doesn't support ";", then you're stuck 
>with a minor flaw in your HTML code. 

Nope. Not at all. I'd suggest perusing the quoted text again.

The recommendation is entirely a convenience issue. There is neither a need
nor a creditable reason to have this ~minor flaw~ in HTML code.

>Does anyone know which HTTP servers support the
>correct code?

In the case of CGI applications, it is entirely an issue of the individual
application. Personally, I have occasionally followed the older
recommendation (to work multiple ways), and found it far more trouble than
any perceived gain. But my scripts are either invoked via forms (where it
is not an issue) or are links within generated pages (where it is a trivial
a consideration, just part of the task.

The quote above is one of the more absurd parts of the HTML 4.0
specification. This is because the very genesis of the confusion is within
the HTML way of encoding of form parameters using the & as a delimiter. (My
late grandfather might have chided them for ~do as I say, not as I do~.

The reality is that many scripts are invoked both via HTML forms and via
explicit URLs. In the former, the & is needed, in the later mildly pesky.

With the luxury of 20-20 hindsight, it is easy to suggest that this design
issue might have been avoided. Never the less, it is hardly a big deal...
no reason to make one of it.

Safe computing,  /Harold

ps. As an example, consider a CGI script that does school science
demonstration, with parameters of amp= and volt= and load=. Observe what
happens when the & is not quoted in a URL within an HREF attribute,
depending on the order of the parameters. <g>
Harold A. Driscoll                 mailto:Harold@Driscoll.Chi.IL.US
#include <std/disclaimer>                 http://Driscoll.Chi.IL.US

Received on Wednesday, 26 January 2000 12:19:58 UTC