- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 27 Sep 2009 15:37:00 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
On 9/27/09 2:28 AM, Maciej Stachowiak wrote: > This is not an issue for DOM methods. It's an issue for interfaces such > as HTMLCollection and HTMLFormElement that support indexing by function > call syntax, for legacy compatibility reasons. Huh. Gecko hasn't supported this, and we haven't had problems with it. Is it really for legacy compat reasons, of just because more than one vendor happens to support it without really knowing why, like tags() on HTMLCollection? Did Webkit and Opera have particular compat issues without implementing this stuff? For what it's worth, I just tested and it looks like Opera and Webkit support () on HTMLCollection; the former doesn't support it on the return value of getElementsByTagName while the latter does. Gecko does not support either. The spec also has the () thing going on for HTMLFormControlsCollection; again we've never had any serious compat problems with this in Gecko. As for HTMLFormElement, while the spec says what it says, it's not exactly for "compatibility reasons" other than "IE must be willing to implement this spec and nothing outside this spec", I assume. Both Opera and Webkit throw in this testcase: <!DOCTYPE html> <body> <form name="foo"> <input name="bar"> <script>try { alert(document.foo("bar")); } catch(e) { alert(e); } </script> whereas they should return the input, per spec. I hadn't realizes the spec required this syntax, and I would be somewhat interested in understanding why it does and whether it's actually required "for compatibility reasons" (in the sense that a new UA on the market would have to implement it to be compatible with existing sites). -Boris
Received on Sunday, 27 September 2009 19:37:50 UTC