14

Consider the following code:

<html>
<head></head>
<body>
<div id='test' class='blah'>
  <a href='http://somesite.com/' id='someLink'>click!</a>
</div>
</body>
</html>

So I just recently discovered that this creates a javascript object called someLink and I can for instance get the value of the href attribute with someLink.href. I tested this in the latest Chrome, FF and IE and it works.

First off, how long has this "feature" been around? I imagine probably a while, because I have known for years that IDs for html elements on a page must be unique, and if you do have more than one element sharing the same ID, the last one overwrites the previous one(s), and using for instance getElementById() will return the last one. But I never really understood why, but now, looking at it as a "this is creating an object" perspective, it makes sense. So, as far as being able to directly access it with the id-name-as-javascript object...how long has that been around? IE6 era? Earlier?

2nd...I guess this is more of a discussion point than question, but... IMO this doesn't seem like a very good "feature" to have... Isn't the whole point of having a DOM and wrapper functions like getElementById(), to give some organization and more importantly, cut down on namespace issues? I don't feel I should have to be worried about random html elements on a page overwriting my javascript variables (something that has recently happened, which is why I discovered this "feature"). Does anybody know why this is as it is, what's the logic behind it?

slinkhi
  • 947
  • 4
  • 16
  • 32
  • "I have known for years that IDs for html elements on a page must be unique, and if you do have more than one element sharing the same ID, the last one overwrites the previous one(s), and using for instance getElementById() will return the last one" As far as I know, `getElementById()` will return the **first**, not the last, element that has the given ID; though it's definitely not consistent (or, at least, shouldn't be relied upon being consistent). – Anthony Grist Mar 16 '12 at 15:44
  • 6
    You hit the nail on the head with your second point. It's *not* a good feature to have, which is why it's been deprecated since forever and wont work if you're using the `"use strict"` directive. – zzzzBov Mar 16 '12 at 15:45
  • Using the Chrome browser, `use strict` still enables the above feature. Just test and see for yourself. Then, you may despise, but element id's should be globally unique, so why not make it global var's? Other than taste, I see no problems, contrary! – Roland Sep 03 '19 at 14:22

3 Answers3

12

First off, how long has this "feature" been around?

It is a Microsoft-ism that cropped up around IE 4 if I remember correctly.

Some other browsers have added support for it in an effort to be compatible with badly written code that depends on it. Some may only support it in quirks mode.

this doesn't seem like a very good "feature" to have

Correct. Don't use it. :)

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
4

Yes, it's been around for a very long time, which is likely the only reason it exists. Removing such a "feature" will break compatibility with existing web sites, which browser vendors are very reluctant to do.

You're correct in saying that it's not a good idea. It's a profoundly bad idea and can lead to naming conflicts as well as unnecessary pollution of the global namespace.

Andy E
  • 338,112
  • 86
  • 474
  • 445
1

It's an old IE feature, not recommended to use. Several browsers implement it, often as nonenumerable properties of the window object. FF, for example, does it only in quirks mode.

For further reading see duplicate Is there a spec that the id of elements should be made global variable?...

Community
  • 1
  • 1
Bergi
  • 630,263
  • 148
  • 957
  • 1,375