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

Re: [whatwg] HTML 5 : Misconceptions Documented

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 18 Jan 2009 13:23:06 -0500
Message-ID: <4973738A.7050306@mit.edu>
To: Mike Wilson <mikewse@hotmail.com>
CC: HTML WG <public-html@w3.org>

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
Received on Sunday, 18 January 2009 18:23:49 UTC

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