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

Re: equals sign in unquoted attribute

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 29 Jul 2009 14:54:06 +0200
Message-ID: <4A70466E.60608@lachy.id.au>
To: Ian Hickson <ian@hixie.ch>
Cc: "public-html@w3.org" <public-html@w3.org>
Ian Hickson wrote:
> On Tue, 14 Jul 2009, Lachlan Hunt wrote:
>> Ian Hickson wrote:
>>> On Fri, 19 Jun 2009, Simon Pieters wrote:
>>>> I think the spec should allow = in unquoted attribute values again,
>>>> because it seems annoying to have to quote href attributes when the URL
>>>> has an =.
>>>
>>> <img src=foo.jpeg alt= class=photo>
>>
>> It just depends whether you think it's more valuable to catch
>> errors  like that, or to allow something much more common
>> like this, copied from google.com:
>>
>> <a href=/advanced_search?hl=en>Advanced Search</a>
>
> I think it's better to catch these errors than allow quote omission in
> those edge cases.

I hardly think the above is an edge case.  Having equals signs in URLs 
is very common, as is using them in links.  I suspect the edge case 
would be the error of people writing attributes like foo= with no quotes 
or attribute value following it, but, unfortunately, I don't yet have 
any data to back that up beyond my own observation.

Do you have any data to support either position, from any of the 
previous stats you've collected?

An alternative solution to consider is to make whitespace before 
unquoted attributes invalid.  This much simpler than the solution 
suggested by Simon, and has the advantage of working as intended for 
both cases above.  It would make the following invalid:

<div class= foo>

But I don't think that would be a significant loss.  From my experience, 
the vast majority of authors don't put space before or after the equals 
sign anyway.  However, doing so could still be valid for quoted 
attributes though:

<div class= "foo">

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Wednesday, 29 July 2009 12:54:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:48 UTC