emulating document.documentElement on pre W3C DOM browsers

[Aaron Gray]

(Please tell me if this is silly or I am barking up the wrong tree)

Can someone check this please on pre W3C DOM browsers :-

function getDocumentRoot()
{
for ( e in document.childNodes)
if ( document.childNodes[e].nodeName == "HTML")
return document.childNodes[e];
return document.body;
}

if (!document.documentElement)
document.documentElement = getDocumentRoot();

There's an html test page here :-

http://www.aarongray.org/Test/JavaScript/documentElement-test.html

There's also a test for document.getElementById() emulation here :-

http://www.aarongray.org/Test/JavaScript/document.getElementById-test.html

Many thanks in advance,

Aaron

 

[Aaron Gray]

if (!document.documentElement)
document.documentElement = getDocumentRoot();

Minor behavioural amendment :-

if (!document.documentElement)
{
document.documentElement = getDocumentRoot();
document.documentElement.readOnly = true;
}

Aaron

 

[SAM]

Aaron Gray a écrit :

news:[email protected]...

Your page-test works well with my Fx.3
(while it is not W3C compliant)

Minor behavioural amendment :-

if (!document.documentElement)
{
document.documentElement = getDocumentRoot();

on my idea the next line will be not used.

'HTML' has been written on the page
so, probably, there is no more existing JS.

document.documentElement.readOnly = true;
}

if (!document.documentElement)
{
document.documentElement = getDocumentRoot();
document.documentElement.readOnly = true;
alert('vu');
}

the alert doesn't fire

 

[Aaron Gray]

Aaron Gray a écrit :

Your page-test works well with my Fx.3
(while it is not W3C compliant)


on my idea the next line will be not used.

'HTML' has been written on the page
so, probably, there is no more existing JS.
Great.


if (!document.documentElement)
{
document.documentElement = getDocumentRoot();
document.documentElement.readOnly = true;
alert('vu');
}

the alert doesn't fire

Okay Fx.3 does not support the readOnly attribute then.

Thats annoying as AFAICS theres no real fix for that

Aaron

 

[dhtml]

(Please tell me if this is silly or I am barking up the wrong tree)

Can someone check this please on pre W3C DOM browsers :-

Don't do this:

    {
        for ( e in document.childNodes)
            if ( document.childNodes[e].nodeName == "HTML")
                return document.childNodes[e];
        return document.body;
    }

for in enumerates and does this up the prototype chain. In Firefox,
"item" will be enumerated, e.g document.childNodes['item']. This is
inefficient and undesirable.

 

[Aaron Gray]

(Please tell me if this is silly or I am barking up the wrong tree)

Can someone check this please on pre W3C DOM browsers :-
Don't do this:
{
for ( e in document.childNodes)
if ( document.childNodes[e].nodeName == "HTML")
return document.childNodes[e];
return document.body;
}

for in enumerates and does this up the prototype chain. In Firefox,
"item" will be enumerated, e.g document.childNodes['item']. This is
inefficient and undesirable.

Okay so I use Array iteration rather than object iteration, thus :-

for ( var i = 0, N = document.childNodes.length; i < N; ++i)
if ( document.childNodes.nodeName == "HTML")
return document.childNodes;
return document.body;

I just learned that lesson else where

Thanks,

Aaron

 

[Richard Cornford]

(Please tell me if this is silly or I am barking up the
wrong tree)

Yes and Yes.

Can someone check this please on pre W3C DOM browsers :-

There is no need because Netscape 4 and IE 4 have no - childNodes -
collections/nodeLists. IE 4 had - children - collections, but not on the
document object if I recall correctly) and Netscape 4 had no means of
accessing an HTML element (because it could not be made into a layer
with CSS).

function getDocumentRoot()
{
for ( e in document.childNodes)

The for-in statement throws and exception if the expression on the right
of the - in - is not type-convertible into an object, so IE 4 and
Netscape 4 exit here.

if ( document.childNodes[e].nodeName == "HTML")
return document.childNodes[e];
return document.body;

Netscape 4 has no - docuemnt.body - either.

}

<snip>

Richard.

 

[Aaron Gray]

Yes and Yes.

Right

There is no need because Netscape 4 and IE 4 have no - childNodes -
collections/nodeLists. IE 4 had - children - collections, but not on the
document object if I recall correctly) and Netscape 4 had no means of
accessing an HTML element (because it could not be made into a layer with
CSS).


The for-in statement throws and exception if the expression on the right
of the - in - is not type-convertible into an object, so IE 4 and Netscape
4 exit here.

Okay that has been moded to an array indexing for loop.

if ( document.childNodes[e].nodeName == "HTML")
return document.childNodes[e];
return document.body;

Netscape 4 has no - docuemnt.body - either.
Right

}

<snip>

Richard.

Great, thats cut the lower end off at IE4 and NN4.

Thanks,

Aaron

 

[Gregor Kofler]

Aaron Gray meinte:

Okay so I use Array iteration rather than object iteration, thus :-

for ( var i = 0, N = document.childNodes.length; i < N; ++i)
if ( document.childNodes.nodeName == "HTML")
return document.childNodes;
return document.body;

I just learned that lesson else where

Ok. Now add curly brackets - and it looks more like JavaScript ("N"
should become "n", too). You know JSLint [1]?

Gregor

[1]
http://www.jslint.com/

 

[Aaron Gray]

Aaron Gray meinte:

Okay so I use Array iteration rather than object iteration, thus :-

for ( var i = 0, N = document.childNodes.length; i < N; ++i)
if ( document.childNodes.nodeName == "HTML")
return document.childNodes;
return document.body;

I just learned that lesson else where

Ok. Now add curly brackets - and it looks more like JavaScript ("N" should
become "n", too). You know JSLint [1]?

Gregor

[1]
http://www.jslint.com/

Thanks, have not got to Lint'ing things yet. I did not like that N either

Aaron

 

[Richard Cornford]

Great, thats cut the lower end off at IE4 and NN4.

So which "pre W3C DOM browsers" come after IE 4 and NN4? I suppose
Konqueror 2 might have fallen into that gap, but its "experimental"
script engine was so far short of any ECMAScript specification that it
could hardly execute scripts at all (and certainly nothing modern (not
having support for, for example, function expressions)).

Richard.

 

[SAM]

Gregor Kofler a écrit :

[1]
http://www.jslint.com/

JSLint is completely mad if not crazy !
Only trying to follow how it thinks indentations have to be
gives a code unreadable for me.

 

[Aaron Gray]

So which "pre W3C DOM browsers" come after IE 4 and NN4? I suppose
Konqueror 2 might have fallen into that gap, but its "experimental" script
engine was so far short of any ECMAScript specification that it could
hardly execute scripts at all (and certainly nothing modern (not having
support for, for example, function expressions)).

Thanks Richard, that hopefully just about wraps that one up then.

Aaron

 

[Aaron Gray]

Gregor Kofler a écrit :

[1]
http://www.jslint.com/

JSLint is completely mad if not crazy !
Only trying to follow how it thinks indentations have to be
gives a code unreadable for me.

Oh! Have not had chance to try it out yet ! Could be fun, or maybe not fun


What indenting scheme do you use ?

Aaron

 

[Gregor Kofler]

SAM meinte:

Gregor Kofler a écrit :

[1]
http://www.jslint.com/

JSLint is completely mad if not crazy !

It isn't. It's perfect for tracking down those otherwise extremely hard
to find bugs.

Only trying to follow how it thinks indentations have to be
gives a code unreadable for me.

What indentations? JSLint normally offers explanations why to follow
certain practices and guidelines. My code stays perfectly readable - in
fact I didn't have to change anything of my usual formatting.

Gregor

 

[SAM]

Gregor Kofler a écrit :

SAM meinte:

Gregor Kofler a écrit :

[1]
http://www.jslint.com/

JSLint is completely mad if not crazy !

It isn't. It's perfect for tracking down those otherwise extremely hard
to find bugs.

Perhaps, I don't know.
Which checkboxes do you choose for that ?

What indentations? JSLint normally offers explanations why to follow
certain practices and guidelines. My code stays perfectly readable - in
fact I didn't have to change anything of my usual formatting.

He bien, tant mieux.

I use to do ie :

if(truc>0) {
dothat();
if(foo) return;
}

or in expanded, delayed, that I rarely use :

if(truc>0)
{
dothat();
if(foo)
{
return;
}
}


and I think JSLint wants

if ( truc > 0 )
{
dothat();
if ( foo )
{
return;
}
}

With these '{' '}' not aligned on the contained instructions
and all this almost blank lines and all these white spaces
I'm lost :-(

I have only a 20" screen.
(my way : 4 lines, JSLint way : 8 lines)

 

[Gregor Kofler]

SAM meinte:

JSLint doesn't like that.

if(foo) return;

if(foo) { return; } is "correct".

and I think JSLint wants

if ( truc > 0 )
{
dothat();
if ( foo )
{
return;
}
}

Nope.

JSLint wants it the Kernighan-Ritchie style

if ( truc > 0) {
if(...) {
}
}

It prvents the bugs induced by the auto semicolon insertion. JSLint
doesn't care about indentation.

I have only a 20" screen.
(my way : 4 lines, JSLint way : 8 lines)

No. It becomes less.

Gregor

 

[SAM]

Gregor Kofler a écrit :

JSLint wants it the Kernighan-Ritchie style

if ( truc > 0) {
if(...) {
}
}

So I didn't check the good checkboxe(s) on my last try of JSLint ?
(recommended options)

 

[Gregor Kofler]

SAM meinte:

Gregor Kofler a écrit :

So I didn't check the good checkboxe(s) on my last try of JSLint ?
(recommended options)

I normally use the default checkboxes.

In your example above JSLint accepts
if()
{..
}

However,
if() foo();
is not accepted.

Gregor

 

[SAM]

Gregor Kofler a écrit :

SAM meinte:

I normally use the default checkboxes.

In your example above JSLint accepts
if()
{..
}

However,
if() foo();
is not accepted.

Yes yes yes understood (while these missing {} are optional)

but with my "normal" way ...
30 lines to tell white spaces missing and wrong indentation
Without forgiving unknown variables