- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 23 Oct 2009 22:09:53 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: HTML WG <public-html@w3.org>
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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 23 October 2009 21:56:58 UTC