Netscape compatibility

[Dr John Stockton]

JRS: In article <[email protected]>, dated Mon, 11
Oct 2004 13:38:02, seen in Mark Preston

Please note that the PR version of the final Firefox will also support
"document.all" for compatibility with poorly written code. Not, I feel,
a good idea but certainly an understandable move.

If document.all is present in addition to document.getElementById
and/or document.layers then ISTM that multi-browser code which tests
for such entities should be reviewed to see whether the tests are
correctly prioritised.

I believe that the code in FAQ 4.15, and the code that was earlier there
and recognised document.layers, will pass that review.

My version of that earlier code is probably OK as is, but I see in it
some commented-out warning code ...

Perhaps someone could check <URL:http://www.merlyn.demon.co.uk/js-
date2.htm#RC> in the PR version, just to see whether running text-
clocks appear.

 

[Randy Webb]

Dr John Stockton wrote:

Perhaps someone could check <URL:http://www.merlyn.demon.co.uk/js-
date2.htm#RC> in the PR version, just to see whether running text-
clocks appear.

Yes, it appears. The entire section appears the same to me in IE6 SP2 as
is it does in Firefox PR

 

[Richard Cornford]

Mark Preston posted :

If document.all is present in addition to
document.getElementById and/or document.layers then
ISTM that multi-browser code which tests for such entities
should be reviewed to see whether the tests are correctly
prioritised.

The Mozilla authors have taken the (in my opinion bad, and strange)
decision to implement - document.all - such that it is not detectable
(by typeof or type-converting) so properly structured feature detecting
code will never notice it.

If by prioritised you mean which of the various methods should be the
preferred choice for element reference retrieval,I would still go with -
document.getElementById -, not because it is W3C standard but because it
is the most well defined, and limited, in the behaviour that should be
expected of it. It is possible to add code that will make -
document.all - behave exactly like gEID, but emulating all of -
document.all - on W3C standard only browsers (are there any of those
left now?) is a lot more involved than writing:-

document.all = document.getElementByTagName{'*');

Richard.

 

[Grant Wagner]

The Mozilla authors have taken the (in my opinion bad, and strange)
decision to implement - document.all - such that it is not detectable
(by typeof or type-converting) so properly structured feature detecting
code will never notice it.

I am not defending their decision, but I would imagine the Mozilla authors'
rational for the - document.all - behaviour to be something akin to:

By supporting - document.all - in a way that is not detectable in properly
structured feature detecting code, they eliminate the possibility that the
less-well-supported document.all path will be chosen. However, if the script
is so badly written that it simply assumes document.all will be available,
the code (hopefully) won't fail.

In other words they want the W3C-compatible path taken when presented with:

if (document.all) {
// path not taken by FF 1.0PR
}
if (document.getElementById) {
// path taken by FF 1.0PR
}

but they want something like this to work

<script language="JavaScript1.2">
<!--
// badly written JavaScript here
document.all.myDiv.style.color = 'Red';
//-->
</script>

Personally I think supporting - document.all - will just perpetuate poorly
written code, but I can understand why they have chosen to support it, even
in a limited fashion. They have probably simply gotten tired of being told
their browser is "broken" because it does not work on the many, many, many
poorly authored sites that cater solely to Internet Explorer.

 

[Richard Cornford]

I am not defending their decision, but I would imagine the
Mozilla authors' rational for the - document.all - behaviour
to be something akin to:

By supporting - document.all - in a way that is not detectable
in properly structured feature detecting code, they eliminate
the possibility that the less-well-supported document.all path
will be chosen.

This move makes it questionable as to the extent to which -
document.all - is less well supported (at least when all the gecko users
have updated). Of the scriptable W3C DOM standard dynamic visual
browsers; IE 5+, Opera 7, Konqueror, Safari, Gecko browsers, IceBrowser
and probably others, will support - document.all -, along with less
dynamic W3C browsers like NetFront and Opera 6 (more or less). And with
IE 4 falling into the - document.all - only camp (and probably not being
alone there), Mozilla's decision might have swing the numbers away from
gEBI.

It is a bit like - innerHTML -, it is not DOM standard but it is very
well supported and so difficult to justify not using it on the grounds
that it is not standard.

Personally I think supporting - document.all - will just
perpetuate poorly written code, but I can understand why
they have chosen to support it, even in a limited fashion.
They have probably simply gotten tired of being told their
browser is "broken" because it does not work on the many,
many, many poorly authored sites that cater solely to
Internet Explorer.

I agree with your proposed motivation, and that it will perpetuate
poorly written code, but I suspect that denying the possibility of
detecting an implemented feature will act to undermine feature detecting
itself and encourage an attitude of charging in with code that "woks"
and never addressing the consequences of its failure.

Personally I don't mind whether Mozilla implements it or not, I am not
going to prefer to use it because it is more chaotic in its behaviour
than gEBI (returning collections sometimes and allowing at least three
distinct methods of indexing its contents (at latest on the latest
IEs)). But if it is there it should be possible to know that it is
there.

That would however be near catastrophic because of the:-

isNet6Plus = Boolean(document.getElementById && !document.all);
isIE5Plus = Boolean(document.getElementById && document.all);

- style browser detecting that is so (misguidedly) pandemic.

In any event the decision appears to have been made so the consequences
may eventually become apparent.

Richard.

 

[Alexis Nikichine]

This move makes it questionable as to the extent to which -
document.all - is less well supported (at least when all the gecko users
have updated). Of the scriptable W3C DOM standard dynamic visual
browsers; IE 5+, Opera 7, Konqueror, Safari, Gecko browsers, IceBrowser
and probably others, will support - document.all -, along with less
dynamic W3C browsers like NetFront and Opera 6 (more or less). And with
IE 4 falling into the - document.all - only camp (and probably not being
alone there), Mozilla's decision might have swing the numbers away from
gEBI.

It is a bit like - innerHTML -, it is not DOM standard but it is very
well supported and so difficult to justify not using it on the grounds
that it is not standard.

Besides, the 'all' method is not only applicable to the document object,
but too any HTML element, too, thus permitting to find an element with a
requested ID in only a subtree of the document. I find this useful when
generating complex nodes from (DOM, or textual) templates: I needn't
care about uniquifying (?) all ID attributes, but at most, only the ID
of root template elements.

Cheers,

Alexis