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

[Jonas Sicking]

On Tue, Jun 14, 2011 at 2:00 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 11 Mar 2011, Jonas Sicking wrote:
>> On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Mon, 20 Sep 2010, Mounir Lamouri wrote:
>> >>
>> >> 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">
>> >
>> > Yes they will. The attribute order has no effect. Elements are created
>> > by the parser with their attributes already set:
>> >
>> > # When the steps below require the UA to create an element for a token in
>> > # a particular namespace, the UA must create a node implementing the interface
>> > # appropriate for the element type corresponding to the tag name of the
>> > # token in the given namespace (as given in the specification that defines
>> > # that element, e.g. for an a element in the HTML namespace, this
>> > # specification defines it to be the HTMLAnchorElement interface), with
>> > # the tag name being the name of that element, with the node being in the
>> > # given namespace, and with the attributes on the node being those given
>> > # in the given token.
>> >  -- http://www.whatwg.org/specs/web-apps/current-work/complete.html#create-an-element-for-the-token
>>
>> Except that I don't think this is how any implementation actually works.
>> Nor do I have any desire to write the implementation this way since it
>> means duplicating a lot of code. I'd have to add code which implemented
>> attribute behavior both in some special code path triggered during
>> element creation, as well as code to react to attribute changes
>> triggered by attribute changes in setAttribute/removeAttribute.
>>
>> So far this hasn't been needed and the parsing code basically just calls
>> setAttribute. Unless there are really good reasons to change this I'd
>> like to avoid it. So far I haven't heard of any such reasons.
>
> The spec is defined such that attribute setting during element creation is
> order-agnostic. I believe this is consistent with what authors expect (in
> part based on the confusion I've seen when authors run into cases where
> that isn't the case). How you implement that is somewhat orthogonal to how
> it is specced; if there are specific things that are hard to implement,
> I'm happy to discuss them specifically if you like.

The problem, if I understand things correctly, is that setAttribute is
*not* order agnostic, while the parsing code is expected to be. This
means that we can't use the same code paths for setAttribute and
parsing.

This is not acceptable to us in Gecko. We're not willing to have two
code paths for setting attributes.

/ Jonas