Bug 22678 – HTML serialization doesn't handle boolean properties properly

• Status: RESOLVED
• Resolution: WONTFIX
• Component: DOM

[Stephan Bublava]

Using innerHTML() assigns an empty value to boolean attributes instead of using the attribute name.

Example:

<select id="foo"><option selected></option></select>
<script>alert(document.getElementById("foo").innerHTML);</script>

gives:

<option selected=""></option>

instead of:

<option selected="selected"></option>

Firefox 3 behaves as I would expect in this case.

[Alexey Proskuryakov]

Why is this a problem? The very presence of the "selected" attribute makes the option selected, regardless of its value.

[Stephan Bublava]

(In reply to comment #1)

> Why is this a problem? The very presence of the "selected" attribute makes the
> option selected, regardless of its value.

I stumbled across this when using the DOM-based bookmarklets for validator.nu (http://about.validator.nu/#alt-input).

It reports selected="" as validation error (at least with the HTML 4 parser), which is kind of annoying, since that construct wasn't part of my original markup.

I don't know if there are other more real-world scenarios, where this would be an issue. Probably not, otherwise somebody else would have complained by now...

[Alexey Proskuryakov]

Yes, per <http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.3.4.2>, it can be either 'selected="selected"' or just 'selected'. It would be nice if serialization used the shortened form.

[Darin Adler]

I believe HTML5 prescribes the behavior of setting the value to empty string when parsing markup like that, not to the name of the attribute.

But I’d expect it to serialize as <option selected></option> rather than <option selected=""></option>. I think changing the serialization would fix the validator problem.

[Darin Adler]

The thing to understand here is that there is no special case here for a “boolean property”. It’s just an attribute with no value, and the behavior of the parser and serializer in that case.

[Darin Adler]

Created attachment 59072 [details]
Patch

[Alexey Proskuryakov]

> The thing to understand here is that there is no special case here for a “boolean property”.

This surprises me a lot. The new code creates invalid HTML 4.01 for <div class="">, which is not a great change - even if it's valid HTML5. Serializing <div class=""> as <div class>  is not what any browser does to my knowledge.

I didn't follow whatwg discussions of this, if there were any.

+        (WebCore::appendStartMarkup): Don't append an equal sign or property
+        value if the property value is the empty string.

Does this patch affect XML serialization, too? I believe attributes must always have a value in XML.

[Darin Adler]

Comment on attachment 59072 [details]
Patch

It’s true, there are boolean IDL properties in the DOM. However, content attributes don’t have types, to the best of my knowledge. They are all strings. So it would not makes sense to serialize content attributes that control boolean values differently.

Reading the HTML fragment serialization algorithm in current HTML5 draft, I see that I am wrong about this change, though, so I won’t land it.

[Darin Adler]

Our current behavior is correct for HTML5. I don’t think we should change to match HTML4.

[Alexey Proskuryakov]

> However, content attributes don’t have types, to the best of my knowledge.

There is such a notion in HTML4, see the link in comment 3. Firefox (as of version 3.6.3) behavior indicates that they have it in their serialization code, too.

I think that Firefox behavior has nice traits (besides being both HTML4 and HTML5 compliant, the serialized code just looks nicer). And matching other browsers is good.

Here are some examples from Firefox:

<option selected> -> <option selected="selected">
<option selected=""> -> <option selected="selected">
<option selected="foo"> -> <option selected="foo">
<option class> -> <option class="">

[Darin Adler]

Since HTML5 has a goal to be compatible, we should try to get it changed if we like the HTML4 behavior here. And we can change WebKit too, either before that happens or when it does. Alexey, would you like to pursue this on the appropriate HTML5 mailing lists?

[Alexey Proskuryakov]

Sure, e-mailed whawg mailing list now.

I had a look at HTML5 draft, and there is a notion of boolean content attribute in it too, see <http://www.whatwg.org/specs/web-apps/current-work/#boolean-attribute>.

[Alexey Proskuryakov]

Mozilla folks seem to prefer WebKit behavior to their own, and track this as <https://bugzilla.mozilla.org/show_bug.cgi?id=573918> now. And as Darin mentioned before, we match the current HTML5 spec draft.

Resolving as WONTFIX. We can reconsider if the spec changes, or if Mozilla doesn't fix their bug.