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/complete/common-dom-interfaces.html Multipage: http://www.whatwg.org/C#htmlformcontrolscollection-0 Complete: http://www.whatwg.org/c#htmlformcontrolscollection-0 Comment: Browser inconsistencies in implementing name getters on forms and form element collections Posted from: 85.227.157.71 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.9.168 Version/11.50
See this thread: http://lists.w3.org/Archives/Public/public-html/2011Apr/thread.html#msg389 and Boris' followup in private email: [[ On 7/15/11 5:33 PM, Ian Hickson wrote: > Do you know what changes, if any, you concluded were needed to the spec We didn't conclude anything. We need some info from WebKit on what they're willing to implement, and they haven't responded. That said, I just realized that my initial testcase with IE was just broken because it doesn't correctly implement HTML5 parsing. A corrected testcase: <!DOCTYPE html> <body> <form name="x"> <img name="y"> </form> <script> var f = document.forms["x"]; alert(f.y); alert(document.forms["x"].elements.y); </script> This alerts "[object HTMLImageElement]" and "undefined" which does not match the spec but does match Gecko and Presto (and for that first alert matches WebKit). So I suspect that the spec definitely needs changing here, because it's likely to not be web-compatible. The thing that's interoperably implemented is that form.myName will find <img> elements with name or id "myName" inside the form. Whatever "inside the form" means, esp. in the tables case. That still needs to be tested. ]]
Wait, what? HTMLFormElement.elements is not restricted to form controls???
Yes, it is. But form[name] is not.
Man, this is crazy town. Ok. I need to basically define the form[] stuff independent of the form.elements[] stuff. It'll be defined pretty much as it is now (including the ridiculous memory map) but it won't do the special RadioNodeList stuff and it will fall back on <img>s if there's no other match rather than returning null.
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: Web compat. Note: Interop was not 100% present on edge cases such as the liveness of the NodeLists returned, or what happens when the names are changed dynamically, etc. I've tried to match the majority of browsers for each feature.
Checked in as WHATWG revision r6727. Check-in comment: Try to make the named getter on HTMLFormElement more Web-compatible. http://html5.org/tools/web-apps-tracker?from=6726&to=6727