[whatwg] Elements should be removed from the past names map once it's no longer associated with the form element
rniwa at apple.com
Mon Aug 26 17:30:21 PDT 2013
On Aug 26, 2013, at 4:13 PM, Ryosuke Niwa <rniwa at apple.com> wrote:
> 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:
>> 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.
Let me clarify what I'm proposing again. What I'm proposing is to remove elements from the past names map when those elements are disassociated from the form element to match IE's existing behavior as opposed to that of WebKit and Gecko. It simplifies implementations and confines the effect of this legacy feature.
- R. Niwa
More information about the whatwg