FAQ Topic - Why doesn't the global variable "divId" always refer to the element with id="divId"?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - Why doesn't the global variable "divId" always refer to the element with id="divId"?
-----------------------------------------------------------------------

Microsoft introduced a shortcut that can be used to reference
elements which include an ID attribute where the ID becomes a
global variable. Some browsers reproduce this behaviours but
some, most notably Gecko-based browsers (Netscape and Mozilla),
do not. The best approach is the « document.getElementById »
method, which is part of the W3C DOM standard and implemented
in modern browsers (including IE from version 5.0). So an
element with « id="foo" » can be referenced
with:-

var el = document.getElementById("foo");

http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access

http://www.jibbering.com/faq/faq_notes/faq_notes.html#FAQN4_41


===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

 

[VK]

Microsoft introduced a shortcut that can be used to reference

elements which include an ID attribute where the ID becomes a
global variable. Some browsers reproduce this behaviours but
some, most notably Gecko-based browsers (Netscape and Mozilla),
do not.

Unfortunately it is not totally true anymore. To my greate surprise
somewhere in 1.5.0.x updates Firefox adopted IE's schema.
Having a div like <div id="myDIV">foo</div> and using onload:

function init(){
if ('undefined' = typeof myDIV) {
myDIV = document.getElementById('myDIV');
}
myDIV.style.visibility = 'hidden';
}

Firefox 1.5.0.7 acts exactly as IE does (myDIV is already defined). The
only difference is that it writes to JavaScript Console a humble
suggestion (warning) that "you should use W3C standard getElementById
method instead".

I'm wondering on what minor release W3C was betraded? In release notes
I see no mention of that (looking at a wrong place?)

 

[Michael Winter]

Unfortunately it is not totally true anymore.

It is, to an extent. However, where it isn't, it hasn't been true for a
while.

To my greate surprise somewhere in 1.5.0.x updates Firefox adopted
IE's schema.

When in "Quirks" mode, and only then, Firefox has exposed element
references as properties of the global object since 1.0.x. I only have
one edition of that minor version (1.0.7), and that was a year old four
days ago. I don't remember exactly when the change occurred, but it's
old news, now.

If someone really cares, there's bound to have been people complained
one way or another in Bugzilla at the time.

[snip]

Mike

 

[VK]

When in "Quirks" mode, and only then, Firefox has exposed element

references as properties of the global object since 1.0.x.
If someone really cares, there's bound to have been people complained
one way or another in Bugzilla at the time.

I see it as another enforcement to always use "var" for new variables
whether they are global or local, and in this aspect IE's way is even
semi-"benefitial" to a good programming style. "var" declarations have
precedence over ID's so if one has id="foo" and var foo=true onload foo
will have value true, not HtmlDivElement. From other side there is a
bounch of side effects with such scope extension, so I cannot tell that
I was ever really happy of its existence.

Thanks for your clarification.

 

[Bernard]

VK wrote:

Microsoft introduced a shortcut that can be used to reference
elements which include an ID attribute where the ID becomes a
global variable. Some browsers reproduce this behaviours but
some, most notably Gecko-based browsers (Netscape and Mozilla),
do not.

This "shortcut" is not optional. While this looks convenient
syntactically, this could also cause document element IDs messing up
your script.

Suppose your scripts originate from different authors who are again
different from the HTML author (quite a common scenario today).

In this case that added convenience exposes you to the risk of name
space clashes and subsequent functional failure.

To avoid this you might then want to isolate your scripts from the
page by hiding them inside anonymous expressions which is only
partially effective.

Another way would be to hide your scripts in an <iframe> or <object>,
as suggested in

http://www.w3.org/TR/html4/present/frames.html#sharing-frame-data

This demonstrates how to communicate with script inside <object>.

Has anyone tried this? It would be great if anyone could show me how
that works. It failed when I tried it. An <object> script calling a
function in the enclosing document works, nut an enclosing document
script calling a function inside the <object> fails. Same applies for
<iframe>

Bernard

 

[VK]

Suppose your scripts originate from different authors who are again
different from the HTML author (quite a common scenario today).
In this case that added convenience exposes you to the risk of name
space clashes and subsequent functional failure.

Only if either one (yourself or other author) happened to be a very bad
boy so "var" was not used somewhere to declare a variable (see my
previous post). An explicit scoping "slash" is possible in a very
particular situation when you need to declare a global variable from
within a function/method. In such case an extra test is necessary or
you are in risk to get "Object doesn't support this property or method"
run-time error while trying to do something as harmless as
function myFunction() {
glbVariable_I_want_to_create = true;
}

instead it must be:
function myFunction() {
if ('undefined' != typeof glbVariable_I_want_to_create) {
// think of a better name
}
}

To avoid this you might then want to isolate your scripts from the
page by hiding them inside anonymous expressions which is only
partially effective.

That's the last century technics, bindings (behaviors) are doing it
much easier and more reliable.

Another way would be to hide your scripts in an <iframe> or <object>,
as suggested in
http://www.w3.org/TR/html4/present/frames.html#sharing-frame-data
This demonstrates how to communicate with script inside <object>.

Scripting advises from W3C? I would take them with an extrem caution

frame/iframe communication is definitely possible, start a new thread
if you have a question (but before you may want to search this group
archives as this topic was answered a great number of time).

 

[Richard Cornford]

Has anyone tried this? ...

You should be a bit caution of why you direct your questions to. Remember
that VK's analytic skills do not even extend as far as being able to
determine when 30 likes of his own code does what he expects and when it
does not:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8
Richard.