[whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

Ryosuke Niwa rniwa at apple.com
Mon Aug 26 16:13:53 PDT 2013

On Aug 26, 2013, at 3:53 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/26/13 5:45 PM, Ryosuke Niwa wrote:
>> I propose to change the specification to remove any elements that are no longer associated with the form from the past names map:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map
> Are you sure this doesn't break web pages?  What do UAs do here?  What did they use to do?

IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th test cases.

>> It's strange for elements to linger around forever in the past names map after the element get associated with a new form element.
> I agree, though it's an obvious consequence of certain past implementation strategies.

I think we overlooked it when we added the support for dynamically changing the owner form element.

>> Since IE didn't support form attribute for a long time (or maybe still hasn't?), I don't think there is any compatibility concern.
> I'm not sure what this sentence is saying.

What I mean is the form content attribute of a form control element used as in: myInputInput.setAttribute('form', 'myForm');

> form.foo works in IE last I checked.  So what are you saying IE didn't or doesn't support?

Yes. IE does have that behavior.  What IE doesn't is keeping a form control element in the past names map of a form element once the control got disassociated with the form element.

I think IE's behavior is much saner than what we've implemented in WebKit and Gecko.

- R. Niwa

More information about the whatwg mailing list