[whatwg] HTML 5 : Misconceptions Documented

[Boris Zbarsky]

Mike Wilson wrote:
> Ian Hickson wrote:
>> On Thu, 15 Jan 2009, Garrett Smith wrote:
>>> If I understand this correctly, given a FORM with an INPUT 
>>> named 'b', if I change the name of that INPUT to 'a', then 
>>> form.b should return the element with name="a".
>>>
>>> <snip>
>>>
>>> What is the reason for introducing the "past names map" 
>>> behavior to the form?
>> Compatibility with a legacy IE bug required (acording to 
>> Safari and Firefox devs) by legacy content.

In Gecko, when the name changes we remove the element from the
name-to-element map under the old name and put it back in under the new
one, such that form.elements.namedItem() will return the element under
the new name.

The only thing that leaves that leads to the current behavior is
<https://bugzilla.mozilla.org/show_bug.cgi?id=100499>, right?  That's
behavior due to the way properties work in Spidermonkey, more or less.
Note that since this isn't a core DOM behavior, but rather an artifact
of the JS-to-DOM glue, in this case the behavior will depend on whether
you've accessed the control by name on the form in the past; if the
first such access is after the name change in Gecko, the control will
only be visible under the new name.

Also note what the bug report says about IE doing "the same thing" at
least in some cases.  I don't know whether it also has the "if you
change the name before you access you won't see it under the old name"
behavior...  I also don't know how necessary any of this is for site
compat, and I'm pretty sure we don't have data on that (since we've
never tried to really fix this bug so far).  Did the Safari folks have
such data?  Is it public by any chance?

-Boris