Bug 22678 - HTML serialization doesn't handle boolean properties properly
Summary: HTML serialization doesn't handle boolean properties properly
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All All
: P3 Minor
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-05 02:45 PST by Stephan Bublava
Modified: 2010-06-23 09:54 PDT (History)
3 users (show)

See Also:


Attachments
Patch (14.60 KB, patch)
2010-06-17 22:16 PDT, Darin Adler
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Bublava 2008-12-05 02:45:42 PST
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.
Comment 1 Alexey Proskuryakov 2008-12-05 08:55:07 PST
Why is this a problem? The very presence of the "selected" attribute makes the option selected, regardless of its value.
Comment 2 Stephan Bublava 2008-12-05 09:22:34 PST
(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...
Comment 3 Alexey Proskuryakov 2008-12-05 09:47:29 PST
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.
Comment 4 Darin Adler 2010-06-17 20:40:20 PDT
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.
Comment 5 Darin Adler 2010-06-17 20:41:23 PDT
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.
Comment 6 Darin Adler 2010-06-17 22:16:41 PDT
Created attachment 59072 [details]
Patch
Comment 7 Alexey Proskuryakov 2010-06-17 23:52:35 PDT
> 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.
Comment 8 Darin Adler 2010-06-18 07:14:42 PDT
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.
Comment 9 Darin Adler 2010-06-18 07:15:24 PDT
Our current behavior is correct for HTML5. I don’t think we should change to match HTML4.
Comment 10 Alexey Proskuryakov 2010-06-18 09:05:49 PDT
> 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="">
Comment 11 Darin Adler 2010-06-18 09:23:36 PDT
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?
Comment 12 Alexey Proskuryakov 2010-06-18 10:17:12 PDT
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>.
Comment 13 Alexey Proskuryakov 2010-06-23 09:54:17 PDT
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.