[Bug 16472] New: Consider DOMString? for HTMLInputElement:value IDL attribute

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16472

           Summary: Consider DOMString? for HTMLInputElement:value IDL
                    attribute
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: travil@microsoft.com
         QAContact: public-html-bugzilla@w3.org
                CC: cam@mcc.id.au, mike@w3.org,
                    public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, annevk@opera.com, jonas@sicking.cc


Created attachment 1105
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1105
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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 21 March 2012 20:45:46 UTC