are dom IDs globals now?

[rnd me]

from what i remember, and according to this article, IE turned elements with an ID attrib into global variables under the name of the id. Everyone complained about this and said it was a bad idea.

was i hibernating when the real browsers started doing this as well?

for example, press f11 right now, click console, and paste "notifications_menu". you should see something like this:

<div class=​"vbmenu_popup" id=​"notifications_menu" style=​"display:​none">​

i don't like typing "getElementById", but i don't like surprise globals either. I would think adding new names to window could break a lot of "xxx in window?"-style object sniffs.

Has anyone had anything break because of this, or is it somehow not a terrible idea anymore?

[rnd me]

USAGE:

var elm = el("vbulletin_css");
alert( elm.innerText || elm.textContent );

FIRST:

function el(id){return document.getElementById(id);}

THEN:

var el=document.getElementById.bind(document);

NOW ? :

el=eval;

All three el()s work in all modern browsers, but if that last one doesn't make you feel like grabbing a pitchfork, you belong on the html forum...

[Dormilich]

Originally Posted by rnd me

from what i remember, and according i don't like typing "getElementById", but i don't like surprise globals either. I would think adding new names to window could break a lot of "xxx in window?"-style object sniffs.

didn’t test it too extensively, but it seems that FF uses some sort of getter. while you can address the ID’d element as such (which I also deem a bad idea) the (var in window) test failed (and I didn’t find anything related in the Firebug DOM list).

PS. what does the second post have to do with the first? all 3 examples seem logical (eval() does have the window context, so the reference should work).

[felgall]

You shouldn't be placing your JavaScript in the global namespace. If you make sure that all your JavaScript is local to the function that you define it in then what exists in the global namespace will make no difference as it will be unable to interfere with your script.

Simply define all your code inside an anonymous function and it will become local to that function and not use the global space at all (provided you declare all your variables as required in strict JavaScript).

[rnd me]

Originally Posted by Dormilich

didn’t test it too extensively, but it seems that FF uses some sort of getter. while you can address the ID’d element as such (which I also deem a bad idea) the (var in window) test failed (and I didn’t find anything related in the Firebug DOM list).

PS. what does the second post have to do with the first? all 3 examples seem logical (eval() does have the window context, so the reference should work).

it's almost worse that you can't easily iterate the implicit globals without the dom. That was another big problem with the way IE6 did it, and did't easily let you figure out what names they'd stepped on.


two main issues:
1. novice coders: they already use eval() to get numbered form elements, now they will be eval'ing table rows and everything else under the sun. The forms alone were enough to get coders to recommend not using eval at all, this is just going to encourage that misguided directive to get broadcast even louder.


2. hampered sniffing. I like knowing that window.XML, window.URL, window.btoa, etc mean what they are supposed to. If the browser doesn't have the named method i look for, i do something else; no biggie. But, the way i've been determining the feature's presence, which is not uncommon, is to simply ask if(window.btoa){...}. I figure if it is taken, it's with a replacement polyfill.

Now i have to go back and retype them. the shortest one i could come up with is if(window.btoa && !window.btoa.id){...}. i guess for btoa, i could do "typeof btoa", but not all the native globals are functions, URL and alert in IE for example...



@felgall: while i agree that using local is good, i don't see what that has to do with the problems stemming from introducing new and novel globals. I mean, i was worred about all the new one like FormData, File, FileReader, etc, but moving IDs to globals blows the barn door off my stable of concerns. since the IDs are 2nd-class to user-defined globals, old code would work just the same in new browsers under global scope as it would locally in an anon function...

[felgall]

Originally Posted by rnd me

@felgall: while i agree that using local is good, i don't see what that has to do with the problems stemming from introducing new and novel globals.

Well if ALL of the code you use is inside an anonymous function defined using strict mode and declaring ALL variables as local to the function then it makes no difference whatever what the browser decides to make global because you will always be referencing your locally defined version. Any global variables defined by the browser that are not a part of the standards would either not be referenced at all from within your script or would be hidden by the local variables that you define with the same names.

Where your code would be broken by the browser defining a meaning for a variable that you wanted to define to mean something else if you tried to code your definition with global scope, your code will work in all browsers when you define it in local scope.

For example if I want

email = document.getElementById('email').value

then by defining email in local scope I can use that command in all browsers whereas it only works in global scope if the browser doesn't define email itself.