Christopher J. Hahn wrote:
Jim Ley wrote: Christopher J. Hahn wrote:
>ECMAScript implementors should try to stick to
>convention even when extending standards.
but IE's DOM is not tied to ECMAScript, so why should
it follow ECMAScript conventions, surely including
conventions related to all the likely languages is
appropriate - which is exactly what they've done.
Sure, the DOM isn't at all tied to ECMAScript. But the
JScript interface to it is (albeit loosely). It is
appropriate to follow conventions for the language that
is interacting with the interface being exposed by the
DOM implementor, regardless of the language.
With regard specifically to the ability to call a collection in IE in
addition to using a property accessor to achieve the same effect, that
is completely within the ECMAScript language conventions. Because an
ECMAScript function is an object (an augmented instance of the native
ECMAScript object) it may have any number of named properties, including
methods. So it would be relatively easy to create an object that behaved
in exactly the way the IE collections do. A simplified example might
go:-
document.all = function(IdOrName){
return document.all[IdOrName];
}
document.all.item = function(index){
return this[index];
}
document.all[0] = document.all['elementName'] = elementRef1;
document.all[1] = document.all['elementName2'] = elementRef2;
....
//used as:-
var a = document.all('elementName2');
var b = document.all.item(1);
var c = document.all[0];
var d = document.all['elementName1'];
var e = document.all.elementName2;
It would certainly not be appropriate for IE to provide
$object->property
or
# comment
notations though I see no reason why that wouldn't be
considered "extending the standard to work within the
conventions of more likely languages".
They couldn't be considered as extending the standard because they would
represent syntax errors to ECMA 262 compliant implementations. Any
extension must be capable of complying with the syntax rules. IE's
'conditional comments' might be regarded as such an extension, because
they conceal themselves within the existing syntax rules.
Other extensions, in the form of additional methods, object and
properties might produce runtime errors if assumed to exist in
environments that do not support them, but they do not result in syntax
errors.
It would be even more inappropriate for MS to promote the
use of such a proprietary way of doing things, and yet more
so to do it without telling the user that it won't work
anywhere else.
I don't like the way in which the term 'user' is used sometimes. To my
mind the user is the individual at the receiving end, and the user of
javascript/ECMAScript is the _programmer_. And the programmer has some
responsibility to find out what works, where and why, and to do some
testing of what they create appropriate to the context in which it will
be used.
Jim may bemoan the low standards of QA on the Internet (and/or its
apparent total absence in many cases) but the programmer should be doing
some testing prior to sending anything on to QA (particularly as
reasonable QA will be keeping track of which developers are responsible
for which bugs, how many bugs and the time it takes them to fix their
bugs, and passing that information on to management).
I understand what you're saying-- they haven't really done
anything "wrong" by allowing it. "Broken" is a personal
opinion of mine. But they promote it and don't bother to
tell you that it's IE-only, and that's definitely
inappropriate.
<snip>
Microsoft has no reason to be documenting other people's browsers. If
they accurately state what is available in the various versions of their
own browsers, and which features appear in various standards, they are
probably doing what should be expected of them (and more than many other
browser manufacturers do). It is a pity that Microsoft's documentation
is erroneous in some respects, but at least it will tell you what IE is
capable of, and usually shows at lest one way of achieving it.
That Microsoft's examples usually show the various collections being
called is perhaps unfortunate, and it does directly promote non-cross
browser scripting, but it might be questioned whether the fault here is
Microsoft's or the W3C's. When, earlier in the thread you wrote:-
| Granted, these are "extensions" in that they don't go against
| the standard but add functionality to it, but I see that it is
| a deliberate attempt to subordinate the standard, in the same
| way that they did with innerHTML, HTMLElement.all, and others
| that don't fit the *vision* of existing standards.
- you cite examples of Microsoft trying to "subordinate ... existing
standards" that pre-date the DOM standards you assert they try to
subordinate. IE 4 had a DOM that featured - all - collections, innerHTML
and callable collections before there was even a Core DOM standard.
At the time of the release of IE 4 the only other significant scriptable
browser was Netscape 4. Their DOMs differed, and if either inspired the
W3C's DOM thinking it was the IE 4 DOM, with its tree-like structure and
access to all of the elements within the document.
By the time the W3C got around to the HTML DOM, and defining the
interface for the HTMLCollection, Microsoft already had callable
collections. The W3C could have specified in the ECMAScript bindings
that the HTMLCollection interface could be called, after all they had no
problem doing so for the ECMAScript binding of the EventListener
interface. And that would have removed the current issue at a stroke
(except with regard to dinosaurs like Netscape 4).
Richard.
