Created attachment 1105 [details]
Test case for null assignment on common DOMString reflecting values

I just ran into a compatibility issue in IE10 (on site 58.com), where the site ends up assigning the null literal value to the input element's value IDL attribute.

As far as I can tell, IE10 is currently doing the "correct" behavior according to the current definition of the value IDL attribute and WebIDL conversion logic:

<blockquote>
The value IDL attribute allows scripts to manipulate the value of an input element. The attribute is in one of the following modes, which define its behavior:

* value
On getting, it must return the current value of the element. On setting, it must set the element's value to the new value, set the element's dirty value flag to true, invoke the value sanitization algorithm, if the element's type attribute's current state defines one, and then, if the element has a text entry cursor position, should move the text entry cursor position to the end of the text field, unselecting any selected text and resetting the selection direction to none.
</blockquote>
(From HTML5 4.10.7.4)

On the site, the input is type=text, which means the value attribute is in the "value" mode. The value sanitization algorithm for that state just trims line breaks from the value.

Since, the HTMLInputElement interface WebIDL is defined as following:

interface HTMLInputElement : HTMLElement {
   [snip]
            attribute DOMString value;
   [snip]
};

Then the conversion of a null literal value should result in the string "null" being assigned per 4.2.16. of WebIDL.

IE10 places the string "null" in the value of the input type=text field. Unfortunately, the site does not want that to happen, instead, they expect the value to be the empty string so that the placeholder text is put in the input box instead.

At a minimum, I'd recommending changing the value IDL attribute to either:

  [TreatNullAs=EmptyString] attribute DOMString value;
or
     attribute DOMString? value;
(and providing a description of how this IDL attribute handles null (e.g., by setting the value to the empty string)

... to ensure good interop and avoid site issues like the above-specified one.

I did some testing of other reflecting DOM attributes (on DIV and on HTMLInputElement -- see attached) under this same scenario, and IE is pretty consistent about assigning the string "null" in all these cases (going as far back as IE8--likely back to IE6, but I didn't test that).

While IE appears to have the correct behavior in these scenarios per the spec(and this behavior has not changed in some time), I wonder if this is the best behavior. According to the attached test, the other browsers aren't perfectly aligned on an alternate behavior, but none of them match IE at the moment. Interestingly, WebKit based browsers tend to clear the content attribute when null is assigned, whereas Firefox/Opera assign the empty string to the content attribute. This _does_ make a difference with respect to some attributes like "title" where the presence of the attribute (vs. an empty string value) make a difference.