W3C home > Mailing lists > Public > public-html@w3.org > June 2009

Re: [Bug 6670] Allow unescaped &s, at least in attributes that accept URLs

From: Kornel <kornel@geekhood.net>
Date: Mon, 1 Jun 2009 13:21:56 +0100
Cc: public-html@w3.org
Message-Id: <B9E7D617-F2BF-430C-863A-43AA890F84B2@geekhood.net>
To: Julian Reschke <julian.reschke@gmx.de>
On 1 Jun 2009, at 10:59, Julian Reschke wrote:

>>> I meant: "If this mean that it becomes conforming (= "valid"): -1".
>> What exactly do you mean by "it" and what do you have any technical  
>> objections other than negative numbers?
> You are making something "valid" which makes parsing href attributes  
> significantly harder, and which increases the risk of these kinds of  
> references leaking into other formats.
> The only reason you have given was hearsay about reducing the size  
> of certain documents; I have mentioned other ways that reduce the  
> size more significantly, one of which could be deployed right away.

I'm not convinced by Ian's argument either, but I support the change,  
because it makes it easy for authors to paste URLs into HTML.

It does make parsing a little harder, but such parsing is already  
necessary for real-world content, regardless whether that's conforming  
or not.

This syntax has never been conforming before, and yet documents with  
unescaped &s in URLs are very common, so keeping it as a conformance  
error is unlikely to fix the problem in the future.

I realize that a similar thing could be said about other conformance  
errors, but in my personal experience it's much easier to convince  
authors to close all elements, quote attributes, etc. than to make  
them escape all ampersands. Since href with unescaped ampersands seems  
to be sent as-is to the server, authors are usually confused why they  
need to use &amp; at all, and whether it will be sent as-is to the  
server too (I've heard "I can't put &amp; in links, because my server  
uses &, and not &amp;!" a few times).

regards, Kornel
Received on Monday, 1 June 2009 12:22:33 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:48 UTC