[whatwg] Serialization of boolean content attributes

[Ian Hickson]

On Fri, 18 Jun 2010, Alexey Proskuryakov wrote:
> 
> My reading of HTML5 is that boolean content attributes with no value are 
> serialized as e.g. <option selected="">. That's not what shipping 
> versions of Firefox or IE do, and this markup is invalid per HTML 4, 
> which is a concern for some people.
> 
> Here are some examples of what Firefox 3.6.3 does, and what would be my
> preference for WebKit (which currently matches HTML5):
> 
> <option selected> -> <option selected="selected">
> <option selected=""> -> <option selected="selected">
> <option selected="foo"> -> <option selected="foo">
> 
> IE is different, and serializes all these examples as <option selected>. 
> That wouldn't be my preference, since that's invalid XML, but at least 
> it's valid HTML 4.
>
> This is tracked as WebKit bug https://bugs.webkit.org/show_bug.cgi?id=22678

On Fri, 18 Jun 2010, Jonas Sicking wrote:
>
> Serializing boolean attributes as <option selected="selected"> seems 
> like a very bad idea since that means that you're changing the value as 
> you serialize. I.e. if you roundtrip by for example setting:
> 
> myDivElement.innerHTML = myDivElement.innerHTML
> 
> you've change the value of all boolean attribute.

Indeed.


> This leaves us with <option selected> or <option selected=""> which both 
> parse to the same DOM in HTML. Given that basically everyone uses the 
> first syntax, I would say that that is what we should serialize as.
> 
> Obviously we don't want to serialize it this way in XHTML documents as 
> this isn't valid XML, so there I say we should serialize as <option 
> selected="">

On Fri, 18 Jun 2010, Darin Adler wrote:
> 
> This does mean that for HTML the serialization of the attributes depends 
> on the fact that they are boolean attributes. Currently the 
> serialization algorithm in HTML5 doesn't handle attributes differently 
> based on their types. Alexey pointed out to me there no obvious way 
> around this unless we want to end up with things like:
> 
>     <option class>
> 
> Instead of:
> 
>     <option class="">
> 
> But I agree that serializing as <option selected> is aesthetically 
> appealing and matches the most popular syntax used in webpages; and the 
> fact that it matches historical IE behavior is a bonus, too.

On Fri, 18 Jun 2010, Jonas Sicking wrote:
> 
> It would be pretty trivial to make the serializer HTML aware and hold a 
> list of which attribute are 'boolean' in which elements, no? It already 
> is HTML aware for a host of other reasons anyway.

On Fri, 18 Jun 2010, Darin Adler wrote:
> 
> One of the things I like about the current serialization rules is that 
> the engine can parse and then serialize something for an element that is 
> not yet known to the engine and it behaves no differently than one that 
> is know. Attributes are simply strings. Having a different rule for 
> boolean attributes would change that. Not a major concern, but something 
> that bothers me slightly. It’s one thing to be HTML-aware and another to 
> be future-of-HTML-aware.

On Fri, 18 Jun 2010, Henri Sivonen wrote:
> 
> Having to have a list of boolean attributes bothers me, too, from a 
> forward compat (and testing) point of view. It's bad enough that the 
> serializer has to have a list of void elements. Since it's possible to 
> make the serializer not require a list of boolean attributes, I think we 
> should choose the path the doesn't require a list.

[snip further discussion along these lines]

I haven't changed the spec here. I agree with those who say that 
hard-coding knowledge of boolean attributes is a bad idea since we don't 
have to. The hard-coded knowledge in the serialiser so far is all 
knowledge we need to have for compatibility.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'