[whatwg] input element's value should not be sanitized during parsing

James Graham jgraham at opera.com
Tue Sep 21 01:06:40 PDT 2010


On Mon, 20 Sep 2010, Mounir Lamouri wrote:

> Hi,
>
> 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
bar" type='hidden'>
> <input type='hidden' value="foo
bar">
> 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
> created.
> OR
> - 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 [1] 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?

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#creating-and-inserting-elements



More information about the whatwg mailing list