This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dev.w3.org/html5/spec/Overview.html#dom-form-elements > The elements IDL attribute must return an HTMLFormControlsCollection rooted at the Document node, whose filter matches listed elements whose form owner is the form element, ... The specification says "rooted at the Document", so ::elements fo a <form> not in the document tree should be empty. However, IE, Firefox, Opera, and WebKit return non-empty collections for ::elements. <script> var f1 = document.createElement('form'); f1.appendChild(document.createElement('input')); alert(f1.elements.length); </script> This code alerts '1' with major browsers though it should be '0' because <input> is not in the Document tree. I personally like the current definition of the specification, but it's not compatible.
I tend to consider current implementations' behavior more correct. A form contains its elements regardless of whether the form is attached to document. So probably "rooted at the Document node" part (which is both unreasonable and inconsistent with implementations) should be just removed from the spec.
We could also say that orphan nodes or nodes in orphan subtrees shouldn't be associated.
(In reply to comment #2) For me, purpose and conclusion of this comment are unclear. Could you be more informative and verbose?
(In reply to comment #2) > We could also say that orphan nodes or nodes in orphan subtrees shouldn't be > associated. Yeah, it would be very simple, and I like it. But it's not compatible with existing browsers, and I'm afraid it will break existing web sites. If we changed the specification to match the existing browsers, the spec would be: ... return an HTMLFormControlCollection rooted at the Document node if the form element is in the document tree, otherwise return an HTMLFormControlCollection rooted at the form element, ... because we need to handle form controls with 'form' content attributes.
looks like we need to reset the form owner of everyone in the form if the form's ancestor chain changes.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r7093. Check-in comment: Try to match implementations better. http://html5.org/tools/web-apps-tracker?from=7092&to=7093
Checked in as WHATWG revision r7094. Check-in comment: Try to match implementations better. http://html5.org/tools/web-apps-tracker?from=7093&to=7094