W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Browser inconsistencies in implementing name getters on forms and form element collections

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 21 Apr 2011 17:45:23 -0400
Message-ID: <4DB0A573.6040004@mit.edu>
To: Simon Pieters <simonp@opera.com>
CC: HTML WG <public-html@w3.org>
On 4/18/11 3:01 AM, Simon Pieters wrote:
> Intersection
> name and id
> log: form: button, fieldset, input, img, keygen? (in Firefox keygen is a
> macro), object, select, textarea
> log: elements: button, fieldset, input, keygen? (in Firefox keygen is a
> macro), object, select, textarea
> (I don't have IE to test with currently.)

IE9 gives me:

log: form: button, embed, input, img, object, select, textarea
log: elements: button, embed, input, object, select, textarea

log: form: button, embed, fieldset, input, img, object, select, textarea
log: elements: button, embed, fieldset, input, object, select, textarea

So looks like form[string] should look for form.elements[string] and 
then for <img> with name or id equal to string in the form.  We should 
do more experiments to figure out which one of the two takes precedence.

I tried another test, to see what happens with the forms inside tables 
that end up empty.  I had to take out 'plaintext', 'caption', 'col', 
'colgroup', 'body', 'tbody', 'thead', 'tfoot', 'td', 'th', 'tr', 'form' 
out of the list because they closed things too early.  With that, the 
testcases are:



Unfortunately it looks like WebKit just fails on this somehow; I can't 
tell how offhand.  Gecko does the same thing as in the case you tested 
(modulo some bugs that I'm ignoring for the moment).  So does Opera.  So 
does IE, except of course in IE's DOM the <form> actually contains the 
<tbody> in this situation.

So it looks like we need some concept of form-association for <img> or 
something, or spec something for the in-table case that doesn't match 
current UA behavior.  Or something.

> I'd be interested in getting interop, I don't mind so much that the name
> lookup is there. I'd be fine with going with the intersection between
> Opera, Firefox and Chrome for which elements to support with name
> lookup. As it happens, the intersection matches Opera, and I haven't
> heard of compat reasons to add more elements to the list, so I suggest
> we spec that.

See above for some additional things we'd also need to spec if we do this.

Received on Thursday, 21 April 2011 21:45:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:12 UTC