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

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 29 May 2009 19:00:00 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: public-html@w3.org
Message-ID: <Pine.LNX.4.62.0905291855000.11443@hixie.dreamhostps.com>
On Fri, 29 May 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > On Fri, 29 May 2009, Julian Reschke wrote:
> > > > I've tried to do this. The spec text for this is highly unintuitive, but
> > > > I hope it matches practical intuition more than the previous text. I'm
> > > > not compeltely convinced that this is a good idea, so let me know if you
> > > > think this should be changed back.
> > > If this mean that it's not conforming: -1!
> > 
> > I don't understand what you mean.
> 
> 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?


> > > There are better ways to achieve shorter href attributes, such as 
> > > using ";" instead of "&" as query parameter delimiter.
> > 
> > Unfortunately we are stuck with "&" for systems that use form 
> > submission.
> 
> How many of the escaped ampersands in the response to a Google Search 
> are contained in href attributes that point to Google services? Fix 
> those to accept ";" instead of "&", and replace them in the links.

Supporting both '&' and ';' seems like a exercise in bug creation. Parsing 
URIs is hard enough to do right as it is without making things even more 
complicated and adding even more edge cases.


> Furthermore, there are other means to optimize for size, such as using 
> gzip (which saves ~75% on the response I just tried), or using a 
> client-side include mechanism for static parts of the page (this was 
> proposed several times in the past, and rejected as not needed).

And once those have been done, you can still save more bytes by not 
including the "amp;" each time.

But that's academic; this is one of the most common syntax errors and 
there really is no reason why it should be one, as far as I can tell. Why 
would we want to make this a parse error?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 May 2009 19:01:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:37 GMT