Live data from Hacker News

Named element IDs can be referenced as JavaScript globals

css-tricks.com

71–80 of 113 posts

Re: Named element IDs can be referenced as JavaScript globals

#71
post #44

Seems like something that could have been made safer just by name spacing it a bit better. Something like “window.elements.myDiv”? I wonder why the decision to go straight to the root.

The Netscape of the 90s wasn't interested in making features ‘safe’. They were about throwing out features as quickly as possible to see what would stick. The simplest possible syntax is to make named elements available globally, and if that clashes with future additions to the DOM API then well that's a problem for some future idiots to worry about. as a strategy it worked pretty well, unfortunately

As the article points out, this initiative was an 90s IE one and the Gecko team (Firefox, post-Netscape) were against it.

Re: Named element IDs can be referenced as JavaScript globals

#72
post #9
post #5

Now I'm worried of using IDs and finding issues with globals in JavaScript. Seems to be a curious issue to be debugged.

Avoid globals at all costs - use IIFE [1] instead, wrapping your function in parenthesis and invoking it right away. [1] https://developer.mozilla.org/en-US/docs/Glossary/IIFE

It's 2022, you can use ES2015 modules now. We can leave IIFE to the dustbin of the past.

Re: Named element IDs can be referenced as JavaScript globals

#73

Seems like something that could have been made safer just by name spacing it a bit better. Something like “window.elements.myDiv”? I wonder why the decision to go straight to the root.

You can make this yourself with Proxy. I get a lot of mileage out of this:

    // proxy to simplify loading and caching of getElementById calls
    const $id = new Proxy({}, {
        // get element from cache, or from DOM
        get: (tgt, k, r) => (tgt[k] || ((r = document.getElementById(k)) && (tgt[k] = r))),
        
        // prevent overwriting
        set: () => $throw(`Attempt to overwrite id cache key!`)
    });

Now if you have

    
You can just do

    $id.something.innerHTML = 'inside!';

Re: Named element IDs can be referenced as JavaScript globals

#74
>To add insult to the injury, named elements are accessible as global variables only if the names contain nothing but letter.

This doesn't seem to be true as shown within this fiddle: https://jsfiddle.net/L785cpdo/1/

Bear in mind that only undefined elements will be declared this way

Re: Named element IDs can be referenced as JavaScript globals

#76

*rigamorale Should read “rigamarole”

*rigmarole, if we're being pedantic, but I suspect the contemporary spelling "rigamarole" is gaining on the proper spelling, and that's one of the wonderful/terrible things about the English language.

Re: Named element IDs can be referenced as JavaScript globals

#78
post #61

Earlier quoted context omitted.

BTW, in my experience getElementById() is still fastest.

The performance difference is negligible. Both methods can return 70k-100k selections in 10ms.

I had projects where this contributed to a visibly perceivable difference. This may have involved SVG, though.

Re: Named element IDs can be referenced as JavaScript globals

#79
post #74

>To add insult to the injury, named elements are accessible as global variables only if the names contain nothing but letter. This doesn't seem to be true as shown within this fiddle: https://jsfiddle.net/L785cpdo/1/ Bear in mind that only undefined elements will be declared this way

Author here. That was a mistake on my part, it shouldn't have slipped in :) I removed that section, thanks for reporting!

Re: Named element IDs can be referenced as JavaScript globals

#80
post #61

Earlier quoted context omitted.

BTW, in my experience getElementById() is still fastest.

The performance difference is negligible. Both methods can return 70k-100k selections in 10ms.

On what hardware?

Also there's a performance cliff when you have a lot of unique ids (or selectors in use from JS).

When you hit the cache querySelector is primarily a getElementById call and then some overhead to match the selector a second time (which chrome should really optimize):

https://source.chromium.org/chromium/chromium/src/+/main:thi...

But if you have more than 256 selectors and ids in use:

https://source.chromium.org/chromium/chromium/src/+/main:thi...

You'll start to hit the selector parser a lot more and then querySelector will be a fair bit slower going through the CSS parser.

Post reply on HN