On Aug 26, 2013, at 3:53 PM, Boris Zbarsky <[email protected]> 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
