Toby said:
It covers most implementations:
Does it? And what sort of argument is that when anyone can point out that
most browser in use are version of IE and so writing exclusively for the
quirks of IE does as much.
Trident (MSIE), Gecko and WebKit
(Safari) are officially supported,
and Presto (Opera) and KHTML
(Konqueror) seem to work fairly reliably.
Easily the majority of the practical issues with Prototype.js that have
come to my attention have been with Opera, and you yourself were
complaining of issues with KHTML earlier in the week. However, that sort
of pattern is precisely what is to be expected when code is written in
disregard of the standard for the programming langue being employed; you
get support for the two most common browsers and struggle to extend that
to every single additional browser (with the less well know browsers
never getting a look in, regardless of their true capabilities).
Seems to partly work in iCab, but there are certainly some
problems. Not tried Tasman (IE/Mac) yet, but wouldn't expect
it to work -- not that I'd expect a purely ECMA-compliant
implementation to work there either.
Mac IE and iCab have very few incompatibilities with ECMA 262, and
certainly not in areas where they would be expected to be a serious
problem.
Frankly, sticking strictly to ECMAScript and the W3C DOM,
you're unlikely to be able to do much useful in Internet
Explorer,
But that has very little to do with IE's support for ECMAScript, and a
great deal to do with its support for the W3C DOM.
which like it or not,
is a target browser for most.
JScript 5.6 claims to support ECMA 262, 3rd Ed. and only fails to achieve
that in a few minor areas (where its faults are well-known and
avoidable).
For example:
function foo (e)
{
var bar = e.target;
window.alert(bar.id);
}
document.getElementById('bar').onclick = foo;
Complies nicely with standards, but fails miserably in IE.
<snip>
That code does not comply with the standards because the standard says
that the non-core modules of the W3C DOM standard are optional, and IE
has never claimed to support the W3C DOM events module.
But DOM support and ECMAScript compliance are totally different issues.
You would be hard pressed to find a scriptable web browser released this
century that does not claim to support ECMA 262 3rd Ed. and hard pressed
to find significant issues with the conformance in any of them. You can
certainly be pretty sure that a common sub-set of the standard will
function consistently across all.
There is a point in ECMA 262 where it is specified that a particular
action will result in an exception being thrown (and a type of exception
defined to be thrown at that point). There is also a note in that section
saying that implementations may choose not to throw the exception.
Informed programmers wishing to create interoperable code will react to
that situation by assuming that the exception will be thrown (the 'safe'
assumption) at that point, and possibly consider themselves lucky if they
find themselves working in a controlled environment where they can know
the exception will never be thrown.
While the authors of Prototype.js (probably in ignorance of the fact that
what they have written should be expected to throw exceptions) have
created code that depends on the implementations it encounters always
electing to take advantage of the provision provided by the specification
for not throwing the exception. That is, they have written code that
should _not_ be expected to work with ECMA 262 3rd Ed. conforming
language implementations, and with code that is expected to be exposed to
browsers claiming to be ECMA 262 3rd Ed. conforming implementations.
And while it would not be too difficult for that one fault to be
corrected the fact that it was introduced in the first place is very
telling.
Richard.
