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

[Ryosuke Niwa]

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?

https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
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