Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts

    are dom IDs globals now?

    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:

    Code:
    <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?
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #2
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts

    problem, illustrated

    USAGE:
    Code:
    var elm = el("vbulletin_css");
    alert( elm.innerText || elm.textContent );
    FIRST:
    Code:
    function el(id){return document.getElementById(id);}

    THEN:
    Code:
    var el=document.getElementById.bind(document);

    NOW ? :
    Code:
    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...
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #3
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,342
    Thanks
    13
    Thanked 349 Times in 345 Posts
    Quote Originally Posted by rnd me View Post
    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).
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #4
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    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).
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #5
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,373
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by Dormilich View Post
    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...
    Last edited by rnd me; 10-02-2012 at 05:31 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #6
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by rnd me View Post
    @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.
    Last edited by felgall; 10-02-2012 at 11:51 PM.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.


  •  

    Tags for this Thread

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •