W3C home > Mailing lists > Public > public-html@w3.org > August 2010

Input values across type changes

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 24 Aug 2010 23:46:08 -0400
Message-ID: <4C749200.70909@mit.edu>
To: HTML WG <public-html@w3.org>
Consider the following script:

  var input = document.createElement('input');
  input.value = 'myval';
  input.type = 'hidden';
  alert(input.value);

What is the expected string in the alert?  Gecko 1.9.2 and earlier, 
Presto, Webkit all alert "myval".  I don't have IE/Win on hand to test 
right now.

Gecko 2.0, which is trying to implement the HTML5 spec on this matter 
alerts the empty string.  Which is the correct behavior?

Analysis of what's going on:

* In the browsers that show "myval", setting the type _also_
   changes the 'value' content attribute to "myval".
* In the current HTML5 spec, the relevant text seems to be:

     When an input element's type attribute changes state, and when
     the element is first created, the element's rendering and behavior
     must change to the new state's accordingly and the value
     sanitization algorithm, if one is defined for the type attribute's
     new state, must be invoked. (section 4.10.7 "The input element".)

   and the definitions of the "value" IDL attribute's modes, which come
   down to:

     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, and then invoke the value
     sanitization algorithm, if the element's type attribute's
     current state defines one.

     default
     On getting, if the element has a value attribute, it must return
     that attribute's value; otherwise, it must return the empty string.
     On setting, it must set the element's value attribute to the new
     value.
     (Section 4.10.7.3 "Common input element APIs".)

   In my example above, the mode goes from "value" to "default" when the
   type changes.  So the .value assignment does NOT change the "value"
   content attribute, and reading .value after the type change should
   read the attribute.  Nothing in the first paragraph above suggests
   that any other content attributes should change, or that the .value
   setter should be reinvoked after the type change with the .value
   from before the type change, which is what was done before in Gecko
   and is presumably still done in Webkit and Presto.

Am I just missing something in the current spec?  If not, does the spec 
need changing to spec the old interoperable behavior, since it may well 
be needed for web compat?

-Boris
Received on Wednesday, 25 August 2010 03:46:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 August 2010 03:46:47 GMT