13776 2011-08-15 07:01:08 +0000 Browser inconsistencies in implementing name getters on forms and form element collections 2011-10-21 21:36:58 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#htmlformcontrolscollection-0 P3 normal --- 1 contributor ian ian mike Ms2ger public-html-admin public-html-wg-issue-tracking zcorpan public-html-bugzilla oldest_to_newest 55048 0 contributor 2011-08-15 07:01:08 +0000 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 55049 1 zcorpan 2011-08-15 07:03:33 +0000 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. ]] 57780 2 ian 2011-10-04 16:39:15 +0000 Wait, what? HTMLFormElement.elements is not restricted to form controls??? 57837 3 zcorpan 2011-10-05 07:25:27 +0000 Yes, it is. But form[name] is not. 58610 4 ian 2011-10-21 00:34:17 +0000 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. 58659 5 ian 2011-10-21 21:36:40 +0000 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. 58660 6 contributor 2011-10-21 21:36:58 +0000 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