I often hear about "DOM level 1", "DOM level 2", "DOM level 3" and "DOM level 4" and realized that I don't know the difference between any of them or how they relate to each other.
I know the very basics - DOM is Document Object Model, and is what provides access for scripting languages (particularly, but as far as I know, not limited to various versions of ECMAScript, such as ECMAScript 5.1) to access elements of an HTML document. (Some sites I read - such as the dom introduction on quirksmode - say that it's for any XML document, but HTML is a sufficient subset.)
The dates on w3c's DOM technical reports seem to imply that each subsequent DOM level supersedes the previous ones.
Sadly, the best reference I've found to provide clarification has been wikipedia, which seems to say the same - the Standardization section says subsequent levels "added" extra functionality, while not mentioning removing anything.
Now, for my questions, which may be rapid fire, but hopefully express the general state of my ignorance:
What's the relation of one DOM level to another?
Are lower level DOMs complete subsets of higher level DOMs? Has any functionality been removed as the DOM level advances? When I see statements like The level 1 DOM will work fine on an HTML document and In the Level 1 DOM, each object, whatever it may be exactly, is a Node (both from the quirksmode intro), does this imply that such statements are true for levels 2, 3 and 4? (These are all kind of the same question, just asked different ways)
Is citing DOM level really little more than a shorthand way of how modern a user agent must be for a particular function to work?
Obviously, I can study each specification off of the w3c's DOM technical reports, but was hoping to get answers from those with first-hand experience. Just by glancing at the changes section of the spec for DOM level 3, I see that most of the changes from 2 to 3 were additions, though some of the key implementations in the Node interface have changed. Did these changes break anything?
I'd like to do more than just nod sagely next time someone tells me, "Oh, that's DOM level 2, so it's ok," so would welcome any references I have missed or firsthand information that I didn't glean from my research.
First, I'll relate a message from MDN's writeup of DOM levels (emphasis in original):
The DOM used to be written as a set of levels. That is no longer the case. These days it is maintained as the DOM Living Standard. This page provides an historical overview of the olden days.
This is confirmed in a W3C document called "W3C DOM4". We might take that to mean "DOM Level 4", and assume it adds an additional DOM level, but the text of the specification actually says:
This document is published as a snapshot of the DOM Living Specification.
So, this is a historical discussion, but still one worth having.
A "DOM Level" was a collection of specifications that described DOM objects, methods, and behaviors. Higher levels of the DOM specification built on the previous levels. Changes happened in two ways:
The addition of a totally new specification category (e.g., Level 3 adds "Validation" and "Load and Save" specifications, which did not exist in Level 2)
The modification of an existing specification category (e.g. updating the "Core" spec)
Obviously, the first type of change was purely additive, rather than subtractive. The second kind of change also seems to have been nearly exclusively additive, probably because the W3C was interested in preserving backward compatibility with previous versions.
Changes that are not backward-compatible tend to be rare and fairly minor. The Document.doctype change you cite, for example, was actually largely additive. Level 3 added the sentence:
For HTML documents, a DocumentType object may be returned, independently of the presence or absence of document type declaration in the HTML document.
This simply gave greater flexibility to allow DOM implementations to add in a doctype in HTML when the author omitted a <!DOCTYPE>. The only functionality this would break is the ability to programmatically detect the presence of an author-specified doctype, which doesn't seem to be particularly valuable.
Probably the reason you've heard someone say, "Oh, that's DOM level 2, so it's ok," is because DOM level 2 is more widely supported than DOM level 3. In some cases, this isn't even a question of old browser support: Firefox marked their lack of support for the DOM 3's "Load and Save" specification as WONTFIX. All Level 2 specifications, by contrast, are supported pretty well by modern browsers, and enjoy support from much older browsers (since Level 2 is four years older than level 3).
Just a couple of notes on DOM4 to add to apsillers' answer:
... In the Level 1
DOM, each object, whatever it may be exactly, is a Node ..., does this imply that such statements are true for
levels 2, 3 and 4?
That's a definite no. Attributes in DOM4 are not Nodes.
DOM4 makes a number of significant non-backward compatible changes. The attributes are not nodes change is a big one if you're not using javascript or a duck typed language. Also document.createElement() on a XML document will create the element in the http://www.w3.org/1999/xhtml namespace, where earlier levels create the element in no namespace. Browsers have long done this, but typical XML oriented DOM implementations have used the DOM3 and earlier way. That's a big shift if you migrate from a DOM3 implementation to a DOM4 one in a non-browser context.
Related
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?
What is supposed to happen is that ‘named elements’ are added as apparent properties of the document object. This is a really bad idea, as it allows element names to clash with real properties of document.
IE made the situation worse by also adding named elements as properties of the window object. This is doubly bad in that now you have to avoid naming your elements after any member of either the document or the window object you (or any other library code in your project) might want to use.
It also means that these elements are visible as global-like variables. Luckily in this case any real global var or function declarations in your code shadow them, so you don't need to worry so much about naming here, but if you try to do an assignment to a global variable with a clashing name and you forget to declare it var, you'll get an error in IE as it tries to assign the value to the element itself.
It's generally considered bad practice to omit var, as well as to rely on named elements being visible on window or as globals. Stick to document.getElementById, which is more widely-supported and less ambiguous. You can write a trivial wrapper function with a shorter name if you don't like the typing. Either way, there's no point in using an id-to-element lookup cache, because browsers typically optimise the getElementById call to use a quick lookup anyway; all you get is problems when elements change id or are added/removed from the document.
Opera copied IE, then WebKit joined in, and now both the previously-unstandardised practice of putting named elements on document properties, and the previously-IE-only practice of putting them on window are being standardised by HTML5, whose approach is to document and standardise every terrible practice inflicted on us by browser authors, making them part of the web forever. So Firefox 4 will also support this.
What are ‘named elements’? Anything with an id, and anything with a name being used for ‘identifying’ purposes: that is, forms, images, anchors and a few others, but not other unrelated instances of a name attribute, like control-names in form input fields, parameter names in <param> or metadata type in <meta>. ‘Identifying’ names are the ones that should be avoided in favour of id.
As mentioned in the earlier answer this behavior is known as named access on the window object. The value of the name attribute for some elements and the value of the id attribute for all elements are made available as properties of the global window object. These are known as named elements. Since window is the global object in the browser, each named element will be accessible as a global variable.
This was originally added by Internet Explorer and eventually was implemented by all other browsers simply for compatibility with sites that are dependent on this behavior. Interestingly, Gecko (Firefox's rendering engine) chose to implement this in quirks mode only, whereas other rendering engines left it on in standards mode.
However, as of Firefox 14, Firefox now supports named access on the window object in standards mode as well. Why did they change this? Turns out there's still a lot of sites that rely on this functionality in standards mode. Microsoft even released a marketing demo that did, preventing the demo from working in Firefox.
Webkit has recently considered the opposite, relegating named access on the window object to quirks mode only. They decided against it by the same reasoning as Gecko.
So… crazy as it seems this behavior is now technically safe to use in the latest version of all major browsers in standards mode. But while named access can seem somewhat convenient , it should not be used.
Why? A lot of the reasoning can be summed up in this article about why global variables are bad. Simply put, having a bunch of extra global variables leads to more bugs. Let's say you accidentally type the name of a var and happen to type an id of a DOM node, SURPRISE!
Additionally, despite being standardized there are still quite a few discrepancies in browser's implementations of named access.
IE incorrectly makes the value of the name attribute accessible for form elements (input, select, etc).
Gecko and Webkit incorrectly do NOT make <a> tags accessible via their name attribute.
Gecko incorrectly handles multiple named elements with the same name (it returns a reference to a single node instead of an array of references).
And I'm sure there's more if you try using named access on edge cases.
As mentioned in other answers use document.getElementById to get a reference to a DOM node by its id. If you need to get a reference to a node by its name attribute use document.querySelectorAll.
Please, please do not propagate this problem by using named access in your site. So many web developers have wasted time trying to track down this magical behavior. We really need to take action and get rendering engines to turn named access off in standards mode. In the short term it will break some sites doing bad things, but in the long run it'll help move the web forward.
If you're interested I talk about this in more detail on my blog - https://www.tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/.
You should stick to getElementById() in these cases, for example:
document.getElementById('example').innerHTML
IE likes to mix elements with name and ID attributes in the global namespace, so best to be explicit about what you're trying to get.
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...
(...)
Yes, they do.
Tested in Chrome 55, Firefox 50, IE 11, IE Edge 14, and Safari 10
with the following example:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<div id="im_not_particularly_happy_with_that">
Hello World!
</div>
<script>
im_not_particularly_happy_with_that.innerText = 'Hello Internet!';
</script>
<!-- Looking at you W3 HTML5 spec group ಠ_ಠ -->
</body>
</html>
http://jsbin.com/mahobinopa/edit?html,output
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?
What is supposed to happen is that ‘named elements’ are added as apparent properties of the document object. This is a really bad idea, as it allows element names to clash with real properties of document.
IE made the situation worse by also adding named elements as properties of the window object. This is doubly bad in that now you have to avoid naming your elements after any member of either the document or the window object you (or any other library code in your project) might want to use.
It also means that these elements are visible as global-like variables. Luckily in this case any real global var or function declarations in your code shadow them, so you don't need to worry so much about naming here, but if you try to do an assignment to a global variable with a clashing name and you forget to declare it var, you'll get an error in IE as it tries to assign the value to the element itself.
It's generally considered bad practice to omit var, as well as to rely on named elements being visible on window or as globals. Stick to document.getElementById, which is more widely-supported and less ambiguous. You can write a trivial wrapper function with a shorter name if you don't like the typing. Either way, there's no point in using an id-to-element lookup cache, because browsers typically optimise the getElementById call to use a quick lookup anyway; all you get is problems when elements change id or are added/removed from the document.
Opera copied IE, then WebKit joined in, and now both the previously-unstandardised practice of putting named elements on document properties, and the previously-IE-only practice of putting them on window are being standardised by HTML5, whose approach is to document and standardise every terrible practice inflicted on us by browser authors, making them part of the web forever. So Firefox 4 will also support this.
What are ‘named elements’? Anything with an id, and anything with a name being used for ‘identifying’ purposes: that is, forms, images, anchors and a few others, but not other unrelated instances of a name attribute, like control-names in form input fields, parameter names in <param> or metadata type in <meta>. ‘Identifying’ names are the ones that should be avoided in favour of id.
As mentioned in the earlier answer this behavior is known as named access on the window object. The value of the name attribute for some elements and the value of the id attribute for all elements are made available as properties of the global window object. These are known as named elements. Since window is the global object in the browser, each named element will be accessible as a global variable.
This was originally added by Internet Explorer and eventually was implemented by all other browsers simply for compatibility with sites that are dependent on this behavior. Interestingly, Gecko (Firefox's rendering engine) chose to implement this in quirks mode only, whereas other rendering engines left it on in standards mode.
However, as of Firefox 14, Firefox now supports named access on the window object in standards mode as well. Why did they change this? Turns out there's still a lot of sites that rely on this functionality in standards mode. Microsoft even released a marketing demo that did, preventing the demo from working in Firefox.
Webkit has recently considered the opposite, relegating named access on the window object to quirks mode only. They decided against it by the same reasoning as Gecko.
So… crazy as it seems this behavior is now technically safe to use in the latest version of all major browsers in standards mode. But while named access can seem somewhat convenient , it should not be used.
Why? A lot of the reasoning can be summed up in this article about why global variables are bad. Simply put, having a bunch of extra global variables leads to more bugs. Let's say you accidentally type the name of a var and happen to type an id of a DOM node, SURPRISE!
Additionally, despite being standardized there are still quite a few discrepancies in browser's implementations of named access.
IE incorrectly makes the value of the name attribute accessible for form elements (input, select, etc).
Gecko and Webkit incorrectly do NOT make <a> tags accessible via their name attribute.
Gecko incorrectly handles multiple named elements with the same name (it returns a reference to a single node instead of an array of references).
And I'm sure there's more if you try using named access on edge cases.
As mentioned in other answers use document.getElementById to get a reference to a DOM node by its id. If you need to get a reference to a node by its name attribute use document.querySelectorAll.
Please, please do not propagate this problem by using named access in your site. So many web developers have wasted time trying to track down this magical behavior. We really need to take action and get rendering engines to turn named access off in standards mode. In the short term it will break some sites doing bad things, but in the long run it'll help move the web forward.
If you're interested I talk about this in more detail on my blog - https://www.tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/.
You should stick to getElementById() in these cases, for example:
document.getElementById('example').innerHTML
IE likes to mix elements with name and ID attributes in the global namespace, so best to be explicit about what you're trying to get.
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...
(...)
Yes, they do.
Tested in Chrome 55, Firefox 50, IE 11, IE Edge 14, and Safari 10
with the following example:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<div id="im_not_particularly_happy_with_that">
Hello World!
</div>
<script>
im_not_particularly_happy_with_that.innerText = 'Hello Internet!';
</script>
<!-- Looking at you W3 HTML5 spec group ಠ_ಠ -->
</body>
</html>
http://jsbin.com/mahobinopa/edit?html,output
I am currently developing a website that is pure javascript and relies heavily on the jQuery & jQuery UI libraries (this site is not intended for use by a general public, hence progressive enhancement is not a strict requirement for this project). I am encountering a significant memory leak on executing the following code:
oDialogBox = $("<div>...</div>");
/* Add useful things to the dialog box here */
oDialogBox.appendTo("body");
oDialogBox.dialog({
/* Other dialog box settings here */
close: function(event, ui) {
oDialogBox.dialog("destroy");
oDialogBox.remove();
oDialogBox = null;
}
});
At any given time in this dialog box, I am creating, removing and modifying a large number of instances of jQuery UI buttons, multiselects (per the Multiselect widget created by Eric Hynds) and on click event handlers. According to jQuery UI documentation, calling .remove() on oDialogBox should result in all child widgets being unbound and deleted. Yet my detached DOM tree shows a significant number of garbage elements that the GC isn't collecting.
It is highly likely I have missed a large set of closures that need to be finished off safely. How do I do the following:
1) How do I identify which closures are keeping a given detached DOM object alive (either in Firefox or Chrome)?
2) Assuming the complete set of closures is identified, does anything beyond nulling the variable need to be done to assure marking the DOM element for garbage collection?
3) I have also noticed my list of arrays stored by the page is giant and contains references to DOM elements not being gathered by the GC. Is there a documented best practice for cleaning arrays from javascript and allowing all elements to be marked for deletion? (Note: this is a current prime suspect for the source of the memory leak)
I'm afraid that I don't have a great answer for #1. I haven't found any really good tools for this myself, even given how good the development tools have become over the last few years. The best advice I can give is to always keep things in the smallest scope you possibly can. If things don't escape, it's generally easier to simply figure out where the references must be.
As to #2, there can be further concerns. If the object referenced by variable v1 closes over the free variables of some function, removing v1 will not be enough to make them eligible for garbage collection if another variable v2 closes over v1 in some other function. So I guess if you really mean the "complete set of closures", then you should be all set. But this might get hairy. Again, if most object have references only in narrow scopes, these problems are much less severe.
For #3, what sorts of arrays are you discussing? If it's jQuery collections, then perhaps you simply have too many of them around. The only reason I know for them to stay around for a long time is to bind event handlers to them, and that is almost always better handled by event delegation on parent elements. If it's you're own custom arrays, do you really have a good reason to store references to them in arrays that last for any substantial length of time? I've rarely found one.
MDN explains how to use the window.screen object, but also says "DOM Level 0. Not part of specification."
W3Schools says that window.screen.* properties are supported in all major browsers.
If I understand this correctly... window.screen is completely non-standard, but is nonetheless universally supported. Is that right?
If this is the case, are there any cross-browser differences I need to be aware of, or can I just use it? I'm mostly interested in screen.availWidth, by the way.
Quirksmode compatibility tables to the rescue!
http://www.quirksmode.org/dom/w3c_cssom.html#screenview
Most, but not all values are supported by the major browsers.
You should be fine with it.
The reason that it is not part of a standard is because DOM Level 0 was introduced before standards were around. DOM Level 0 is also called the Legacy DOM, and it was created at the same time NetScape 2.0 made JavaScript in the browser a reality; in effect, DOM Level 0 was the very first DOM spec.
The Legacy DOM will be around for a long time, if not then it would break backward compatibility with a TON of very popular scripts already in existence.
EDIT: In other words, your understanding is completely correct. It is not "standardized" but it is completely universal and will remain so for a long time.
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?
What is supposed to happen is that ‘named elements’ are added as apparent properties of the document object. This is a really bad idea, as it allows element names to clash with real properties of document.
IE made the situation worse by also adding named elements as properties of the window object. This is doubly bad in that now you have to avoid naming your elements after any member of either the document or the window object you (or any other library code in your project) might want to use.
It also means that these elements are visible as global-like variables. Luckily in this case any real global var or function declarations in your code shadow them, so you don't need to worry so much about naming here, but if you try to do an assignment to a global variable with a clashing name and you forget to declare it var, you'll get an error in IE as it tries to assign the value to the element itself.
It's generally considered bad practice to omit var, as well as to rely on named elements being visible on window or as globals. Stick to document.getElementById, which is more widely-supported and less ambiguous. You can write a trivial wrapper function with a shorter name if you don't like the typing. Either way, there's no point in using an id-to-element lookup cache, because browsers typically optimise the getElementById call to use a quick lookup anyway; all you get is problems when elements change id or are added/removed from the document.
Opera copied IE, then WebKit joined in, and now both the previously-unstandardised practice of putting named elements on document properties, and the previously-IE-only practice of putting them on window are being standardised by HTML5, whose approach is to document and standardise every terrible practice inflicted on us by browser authors, making them part of the web forever. So Firefox 4 will also support this.
What are ‘named elements’? Anything with an id, and anything with a name being used for ‘identifying’ purposes: that is, forms, images, anchors and a few others, but not other unrelated instances of a name attribute, like control-names in form input fields, parameter names in <param> or metadata type in <meta>. ‘Identifying’ names are the ones that should be avoided in favour of id.
As mentioned in the earlier answer this behavior is known as named access on the window object. The value of the name attribute for some elements and the value of the id attribute for all elements are made available as properties of the global window object. These are known as named elements. Since window is the global object in the browser, each named element will be accessible as a global variable.
This was originally added by Internet Explorer and eventually was implemented by all other browsers simply for compatibility with sites that are dependent on this behavior. Interestingly, Gecko (Firefox's rendering engine) chose to implement this in quirks mode only, whereas other rendering engines left it on in standards mode.
However, as of Firefox 14, Firefox now supports named access on the window object in standards mode as well. Why did they change this? Turns out there's still a lot of sites that rely on this functionality in standards mode. Microsoft even released a marketing demo that did, preventing the demo from working in Firefox.
Webkit has recently considered the opposite, relegating named access on the window object to quirks mode only. They decided against it by the same reasoning as Gecko.
So… crazy as it seems this behavior is now technically safe to use in the latest version of all major browsers in standards mode. But while named access can seem somewhat convenient , it should not be used.
Why? A lot of the reasoning can be summed up in this article about why global variables are bad. Simply put, having a bunch of extra global variables leads to more bugs. Let's say you accidentally type the name of a var and happen to type an id of a DOM node, SURPRISE!
Additionally, despite being standardized there are still quite a few discrepancies in browser's implementations of named access.
IE incorrectly makes the value of the name attribute accessible for form elements (input, select, etc).
Gecko and Webkit incorrectly do NOT make <a> tags accessible via their name attribute.
Gecko incorrectly handles multiple named elements with the same name (it returns a reference to a single node instead of an array of references).
And I'm sure there's more if you try using named access on edge cases.
As mentioned in other answers use document.getElementById to get a reference to a DOM node by its id. If you need to get a reference to a node by its name attribute use document.querySelectorAll.
Please, please do not propagate this problem by using named access in your site. So many web developers have wasted time trying to track down this magical behavior. We really need to take action and get rendering engines to turn named access off in standards mode. In the short term it will break some sites doing bad things, but in the long run it'll help move the web forward.
If you're interested I talk about this in more detail on my blog - https://www.tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/.
You should stick to getElementById() in these cases, for example:
document.getElementById('example').innerHTML
IE likes to mix elements with name and ID attributes in the global namespace, so best to be explicit about what you're trying to get.
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...
(...)
Yes, they do.
Tested in Chrome 55, Firefox 50, IE 11, IE Edge 14, and Safari 10
with the following example:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<div id="im_not_particularly_happy_with_that">
Hello World!
</div>
<script>
im_not_particularly_happy_with_that.innerText = 'Hello Internet!';
</script>
<!-- Looking at you W3 HTML5 spec group ಠ_ಠ -->
</body>
</html>
http://jsbin.com/mahobinopa/edit?html,output