Do DOM tree elements with IDs become global properties?

NICon_58186 0
Viewed 52203

Working on an idea for a simple HTMLElement wrapper I stumbled upon the following for Internet Explorer and Chrome:

For a given HTMLElement with an id in the DOM tree, it is possible to retrieve the <div> using its ID as a variable name or as a property of window. So for a <div> like

<div id="example">some text</div>

in Internet Explorer 8 and Chrome you can do:

alert(example.innerHTML); // Alerts "some text".

or

alert(window["example"].innerHTML); // Alerts "some text".

So, does this mean every element in the DOM tree is converted to a property on the global object? And does it also mean one can use this as a replacement for the getElementById method in these browsers?

getelementbyid global-variables dom html javascript
5 Answers

The question should sound:: "Do HTML Tags with provided IDs become globally accessible DOM Elements?"

The answer is YES!

That's how it was meant to work, and that's why IDs were introduced by W3C to begin with.: The ID of an HTML Tag in a parsed scripting environment becomes its corresponding DOM Element handle.

However, Netscape Mozilla refused to conform to (to them intruding) W3C and stubbornly kept using the deprecated Name attribute to create havoc and therefore break the Scripting functionality and the coding convenience brought in by the W3C's introduction of Unique IDs.

After the Netscape Navigator 4.7 fiasco their developers all went and infiltrated the W3C, whereas their associates were superseding the Web with wrong practices and misusing examples. Forcing the use and reuse of already deprecated Name attribute [!which was not meant to be unique] on par with ID attributes so that scripts that utilized ID handles for accessing particular DOM elements would simply break!

And break they did as they would also write and publish extensive coding lessons and examples [their browser would not recognize anyway] such as document.all.ElementID.property instead of ElementID.property to at least make it inefficient and give the browser more overhead in case it didn't simply break it at HTML domain by using the same token for the (now [1996-97], deprecated) Name and the standard ID attribute supplying it with the same token value.

They easily managed to convince the - back then - overwhelming army of ignorant code-writing amateurs that Names and IDs are practically the same, except that ID attribute is shorter and therefore byte-saving and more convenient to the coder than the ancient Name property. Which was of course a lie. Or - in their superseding published articles of HTML, convincing articles that you'll need to provide both Name and ID to your tags for them to be accessible by the Scripting engine.

Mosaic Killers [codenamed "Mozilla"] were so pissed they thought "if we go down, so should Internet".

The rising Microsoft - on the other hand - were so naive they thought they should keep the deprecated and marked for deletion Name property and treat it as if it was an ID that is a unique Identifier so that they wouldn't break the scripting functionality of old pages coded by Netscape trainees. They were deadly wrong...

And the returning of an array collection of ID conflicting elements was not a solution to this deliberate man-made problem either. Actually it defeated the whole purpose.

And this is the sole reason W3C turned ugly and gave us idiocies such as document.getElementById and the accompanying rococo goddamn annoying syntax of the sort... (...)

user_58964260
Related