[whatwg] input element's value should not be sanitized during parsing
jgraham at opera.com
Tue Sep 21 01:06:40 PDT 2010
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
> For a few days, Firefox's nightly had a bug related to value sanitizing
> which happens to be a specification bug.
> With the current specification, these two elements will not have the
> same value:
> <input value="foo
> <input type='hidden' value="foo
> Depending on how the attributes are read, value will be set before or
> after type, thus, changing the value sanitization algorithm. So, the
> value sanitization algorithm of <input type='text'> will be used for one
> of these elements and the value will be "foobar".
> The following change would fix that bug:
> - The specification should add that the value sanitization algorithm
> should not be used during parsing/as long as the element hasn't been
> - The specification should add in the set value content attribute
> paragraph that the value sanitization algorithm should not be run during
> parsing/if the element hasn't been created.
> For a specification point of view, both changes would have the same result.
> The specifications already require that the value sanitization algorithm
> should be run when the element is "first created".
> So, with this change, the element's value will be un-sanitized during
> parsing and as soon as the parsing will be done, the element's value
> will be sanitized.
The concept of "Creating an Element" already exists  and is atomic,
that is the element is created with all its attributes in a single
operation. Therefore it is not clear to me how attribute order can make a
difference per spec. Am I missing your point?
More information about the whatwg