Live data from Hacker News

Named element IDs can be referenced as JavaScript globals

css-tricks.com

91–100 of 113 posts

Re: Named element IDs can be referenced as JavaScript globals

#91

I'm surprised to find that this trick still works even in the new backwards-incompatible JavaScript Modules (using ), which enables "strict" mode and a number of other strictness improvements by default. I believe it works because the global object ("globalThis") is the Window in either case; this is why JavaScript Modules can refer to "window" in the global scope without explicitly importing it. cool console.log(thi…

There is some effort to standardize something along these lines. Well, some things which combined would achieve this. It’s too late to bake it into ESM, but I believe it’ll be possible with ShadowRealms[1] and/or SES[2], and Built-in Modules (JS STL)[3]. 1: https://github.com/tc39/proposal-shadowrealm 2: https://github.com/tc39/proposal-ses 3: https://github.com/tc39/proposal-built-in-modules

Luckily the Reddit thread has the Yu-Gi-Oh! jokes so I don't have to repeat them here.

Re: Named element IDs can be referenced as JavaScript globals

#92

Earlier quoted context omitted.

Use ids when JS needs to reference unique elements. Use classes for styling and accessing groups.

JS can do just as well with unique classnames, which avoids issues with ids like those given in the article.

I always presumed this would usually entail a performance hit, since you are accessing something that is not defined as unique.

Re: Named element IDs can be referenced as JavaScript globals

#93
post #83

Earlier quoted context omitted.

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

That’s surprising, webkit+blink and I’m guessing gecko all optimize the query selector cases. I assume it’s the cost of the NodeList (because NodeLists are live :-/)

May be worth testing it against getElementsByClassName(), which also returns a live collection.

Re: Named element IDs can be referenced as JavaScript globals

#95

Earlier quoted context omitted.

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

In isolation definitely, but in real world code it might be faster to use querySelector for branchy code if it doesn’t always use an id. As with everything, if it’s not performance-sensitive write the code that’s easier for humans to read, and if it is measure first.

I'm not sure what you're trying to say here, as it's tautologically correct that getElementById can't be used in cases where you want to select on more than just the id. Do you mean a use case where you have branchy code that produces a selector string that has some id only paths?

Re: Named element IDs can be referenced as JavaScript globals

#96

I don't think this article is complete. It mentions no pollution, which is true of window and most HTML elements, but not always. Check this out, you can set an img name to getElementById and now document.getElementById is the image element! Here's a minimal example ( https://jsfiddle.net/wc5dn9x2/ ): // The img object console.log(document.getElementById); // TypeError: document.getElementById is not a function :D co…

Curiously the article doesn't mentions it, but theses kinds of vulnerabilities are named DOM clobbering if you want to know more about it!

It's weirdly not that discussed on the web, most probably because it require a pretty specific situation.

Re: Named element IDs can be referenced as JavaScript globals

#97
post #83

Earlier quoted context omitted.

That’s surprising, webkit+blink and I’m guessing gecko all optimize the query selector cases. I assume it’s the cost of the NodeList (because NodeLists are live :-/)

May be worth testing it against getElementsByClassName(), which also returns a live collection.

I actually just went and tested and in webkit at least my 100% perfect test case I had querySelector taking 2x longer than getElementById. I tried understanding what the current webkit code does but the selector matching code is now excitingly complex due to the CSS JIT.

Many many years ago I recall querySelector starting out with a check for #someCSSIdentifier and shortcutting to the getElementById path, but maybe my memory is playing tricks on me.

Re: Named element IDs can be referenced as JavaScript globals

#98
post #61

Earlier quoted context omitted.

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.

Oh I can definitely see that coming up with SVG or deep extensive XML trees yeah.

Re: Named element IDs can be referenced as JavaScript globals

#99
post #87

Earlier quoted context omitted.

> Is there a reason to not use querySelector getElement is slightly faster, but not by enough to care IIRC so I use querySelector for consistency and it's flexibility. > One reason jQuery became so popular is because the DOM was painful I would say that is the key reason, with everything else being collateral benefits. Assuming you combine element selection, dealing with legacy incompatibilities, and function chainin…

...and portability.

Between browsers?

I was counting that in "dealing with legacy incompatibilities".

Re: Named element IDs can be referenced as JavaScript globals

#100
post #86

I don't think this article is complete. It mentions no pollution, which is true of window and most HTML elements, but not always. Check this out, you can set an img name to getElementById and now document.getElementById is the image element! Here's a minimal example ( https://jsfiddle.net/wc5dn9x2/ ): // The img object console.log(document.getElementById); // TypeError: document.getElementById is not a function :D co…

Note that this is with the name attribute, not the id attribute the article is discussing.

Good catch. That would explain why it wasn't mentioned then
Post reply on HN