- 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:52 UTC