W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: Property enumeration on forms

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 23 Oct 2009 15:03:21 -0700
Message-ID: <63df84f0910231503s16dcc478l253dc9f6c209d605@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>, public-script-coord@w3.org
Cc: Boris Zbarsky <bzbarsky@mit.edu>, HTML WG <public-html@w3.org>
On Fri, Oct 23, 2009 at 3:09 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 23 Oct 2009, Boris Zbarsky wrote:
>>
>> Consider this testcase:
>>
>>   <form id="x">
>>     <input name="myInput">
>>     <input>
>>   </form>
>>
>> If I now do:
>>
>>       var form = document.getElementById("x");
>>       for (var i in form) {
>>         document.writeln(i + " -- " + form[i]);
>>       }
>>
>> I see the following behavior in different engines:
>>
>> Webkit: has properties named 0 and 1 for the two elements
>> Opera: has properties named 0 and 1 for the two elements
>> IE8: has properties named myInput and 1 for the two elements
>> Gecko: has a property named myInput for the first element
>>        (the lack of a property named 1 is just a bug;
>>        it's _trying_ to have one, but failing).
>>
>> None of the browsers seem to have all of 0, 1, myInput in the enumeration.
>> All do what one would expect if actually doing form[1], form[1], form.myInput.
>>
>> Obvious questions:
>>
>> 1)  What should the right behavior be here.
>> 2)  How is one to infer this behavior from the idl?
>> 3)  Should question 2 be asked on public-script-coord instead?
>
> The behaviour cannot be inferred from the IDL. It is only defined in the
> prose, using the terms "indices of the supported indexed properties" and
> "names of the supported named properties", which are then WebIDL terms
> that WebIDL defines the processing of for JS.
>
> The right behaviour per spec is, as you imply, to have all of 0, 1,
> myInput in the enumeration. We could hide some of these if people think
> that's desireable; however, since what the spec is asking for is a union
> of the implemented behaviours, I think that's actually probably more
> useful overall.

I don't really feel strongly on the subject, however it appears that
most people on the public-script-coord felt that catch-alls were a
really bad idea and not something to be furthered. And you could argue
that adding enumerability to the catch-alls is furthering them.

And since it appears that UAs are far from consistent, it's likely not
that much content out there that depend on the enumerability of
catch-alls.

/ Jonas
Received on Friday, 23 October 2009 22:04:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC