- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 24 Aug 2010 23:46:08 -0400
- 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 UTC