This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html Multipage: http://www.whatwg.org/C#association-of-controls-and-forms Complete: http://www.whatwg.org/c#association-of-controls-and-forms Referrer: Comment: Node removal and form association by HTML Parser Posted from: 122.216.99.139 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.29 Safari/537.36
I filed this. The specification says: > When an element is removed from a Document resulting in a form-associated > element and its form owner (if any) no longer being in the same home subtree, > then the user agent must reset the form owner of that form-associated element. None of IE11, Firefox 26, WebKit, and Blink follows this. IE11 behavior: When a form-associated element is removed from a Document, the user agent resets the its form owner. Other browsers: When an element is removed from its home subtree resulting in a ... (the rest is same as the spec.) It seems IE11 wants to support non-tree association by HTML parser only in the document tree, and other browser try to support non-tree association by HTML parser in any home subtree. Proposal: Follow IE11 behavior. Test code: </head> <body> <div id=willBeRemoved> <div> <form id=f1> <input id=input-child> <img id=img-child> </div> <input id=input-outer1> <img id=img-outer1> </div><!-- willBeRemoved --> <input id=input-outer2> <img id=img-outer2> <hr > <pre></pre> <script> function $(id) { return document.getElementById(id); } function log(str) { var c = document.querySelector('pre'); c.innerHTML += str + '\n'; console.log(str); } var f1 = document.querySelector('#f1'); var e = f1.elements; for (var i = 0; i < e.length; ++i) { log(i + ': id=' + e[i].id); } log('form[img-child]: ' + f1['img-child']); log('form[img-outer1]: ' + f1['img-outer1']); log('form[img-outer2]: ' + f1['img-outer2']); log('*** Detach an ancestor of the form and *-outer1 ***'); document.body.removeChild($('willBeRemoved')); for (var i = 0; i < e.length; ++i) { log(i + ': id=' + e[i].id); } log('form[img-child]: ' + f1['img-child']); log('form[img-outer1]: ' + f1['img-outer1']); log('form[img-outer2]: ' + f1['img-outer2']); </script> </body> </html>
(In reply to Kent Tamura from comment #1) > IE11 behavior: > When a form-associated element is removed from a Document, the user agent > resets the its form owner. Correction: When a form-associated element or its form owner is removed from its home subtree, the user agent resets the form-associated element's form owner.
Created attachment 1432 [details] Test case
HTMLFormElement::elements implies we keep association-by-parser only in the document tree. http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-elements > The elements IDL attribute must return an HTMLFormControlsCollection rooted > at the Document node while the form element is in a Document and rooted at > the form element itself when it is not, So, the IE11 behavior is reasonable.
I don't understand why the quote in comment 4 implies that. Can you elaborate?
The idea of the spec as written was that you should be able to move a section of the document to another part of the document, without breaking forms within it. For example: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2776 The radio buttons keep working as a pair, unrelated to the top one, even after you click the button, meaning they're still in the form, even though the whole subtree has been moved out of the tree and back in elsewhere.
(In reply to Ian 'Hixie' Hickson from comment #5) > I don't understand why the quote in comment 4 implies that. Can you > elaborate? "rooted at the form element itself (when it is not in a Document)" means form.elements doesn't contain elements magically associated by HTML parser. If the intention is to keep magical association, we should change the followings. http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-elements "rooted at form element" -> "rooted at the root element of form's home subtree" (in order to form.elements contains magical associated elements) http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html "When an element is removed from a Document resulting in a form-associated element and its form owner (if any) no longer being in the same home subtree, ..." -> "When an element is removed from its home subtree resulting ..." (in order to avoid to associate a form and an element in different home subtrees when a subtree not in a Document is separated into two subtrees)
That's a fair point, I agree that if we keep this association in the orphaned subtree case that we should do that.
I think we want all three of these cases to keep working, as they do in all the browsers I tested (not IE): http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2780 This suggests that we want to go more towards the other browsers than towards IE. Any opinions?
I'm ok to go forward with the keep-magic-association-in-orphan-tree policy.
Checked in as WHATWG revision r8446. Check-in comment: Turns out browsers reset the form owner not just when a node is taken from a document, but also when it's taken from a subtree. which makes sense. http://html5.org/tools/web-apps-tracker?from=8445&to=8446