Re: Property enumeration on forms

On Oct 23, 2009, at 2:41 PM, 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?

Web IDL currently makes all indexed properties and names properties  
enumerable:

http://dev.w3.org/2006/webapi/WebIDL/#indexed-and-named-properties

If there's a need to make any such properties non-enumerable we'd have  
to extend Web IDL. One possible way is to have an explicit  
"enumerator" operation that reports the dynamic properties that  
currently exist; having this be implicit from the properties for which  
the getter would return something seems confusing and indirect.

In this case, I think the union behavior is sensible - hiding index  
properties from enumeration when there is a corresponding named  
property seems weird. I imagine the intent of the IE (and attempted  
Gecko) behavior is that only one property gets enumerated for every  
form element, with preference being given to the named property. If  
it's important to ensure that every element is enumerated only once,  
I'd prefer that to be always by index, since the risk of name  
collision with other things is lower and the behavior is simpler to  
define. But for..in on forms will enumerate lots of things that are  
not form elements at all, so I don't think it's terribly important or  
helpful to guarantee every element is enumerated only once. So the  
union of behaviors seems fine to me.

Regards,
Maciej

Received on Friday, 23 October 2009 22:13:19 UTC