So, here is something weird.
Yesterday I was refactoring some code and came across something akin to this:
const logo = document.getElementById("brand")
brand.style.top = 0
At no point in the codebase was a variable named brand defined. And so any sane observer would expect that the preceding snippet would result in a runtime error -- assuming there was not something like a linter available that would have picked up on it (and the fact that logo was being defined but never used) first.
I started having one of those moments that we all dread: I was looking at some code that could not possibly have ever worked. Yet, there it was. Working. I sank into my chair, not sure to make of what I was seeing.
In fact, the only other place I could see the word "brand" in the entire application was in the HTML document upon which this Javascript was being executed (yes, some websites still send HTML over the wire).
So I changed it:
<div id="brand_foo"> ... </div>
And then, lo and behold, the code instantly started causing a runtime error. Wait. No way... The browser is surely not pre-defining a global variable for each DOM element with an ID attribute. Right?
Wrong! It does. I've looked at this code in most major browsers and mobile devices and not one of them complained.
Don't believe me? You can try it yourself right now. Press F12 (or otherwise Right Click -> Inspect), find an element with an ID, and then evaluate that ID at the console REPL.
What about IDs such as "brand-name" that don't conform to Javascript's grammar? Surely they are ignored? Nope:
window["brand-name"] // --> <div id="brand-name">
I have no idea how well known this is. I certainly did not know about it but, admittedly, I haven't spent a lot of time in the browser in many years. I've reached out to all of the frontend developers I know and none of them knew about this either.
As it turns out, the HTML specification actually documents this functionality. Although it seems major browsers are not implementing it uniformly at all. If you define more than one element with the same ID (you evil person), then Chrome will actually return an array of Element objects whilst Firefox returns the first element it saw. And neither browsers define global variables based on the name attribute on elements like img and a.
Should I make use of this?
No. Please, no. Imagine how confusing this could get if you were dealing with many DOM elements in a non-trivial codebase and none of them were being defined anywhere visible to the programmer. Or imagine if you go all-in and then one day a major browser decides this is insanity and disables it!
The only place I can see this being of use would be in the REPL whilst debugging. But, still, it's kind of cool in a never-do-this kind of way.
Header image originally from http://www.classichorrorcampaign.com
Top comments (36)
Okay, so I'm a bit confused when you say, "yes, some websites still send HTML over the wire". I thought ALL web servers send back HTML when an http request is received for a particular website. I'm still learning guys, so if I'm wrong please help me. Thank you
No, don't sweat it - that is a good question.
It was meant as a subtle jab at the explosion in popularity of frontend frameworks, in which one sends Javascript over the wire and then creates the HTML elements at runtime in the web browser. For example, a React app typically sends Javascript over HTTP and then the web browser executes it to produce the HTML.
So my comment was kind of saying: "Some people still do it the 'old' way"
Since it's still a browser doing the rendering, it needs at least a
scripttag to run the JavaScript(not sure if only having a script tag in an HTML file would be valid HTML5). And usually some more but minimal HTML is still delivered to the browser.Sometimes devs are not aware of it, because this file rarely changes in the code base, or it is "hidden" because the build tool applies some default template.
Yep, absolutely. To clarify, the comment is referring to the HTML elements which make up the visible UI of a particular app. Images, titles, tables, lists, etc, etc. :)
Lol thank you for that. That actually sounds cool! I have to play around with that.
The HTML in modern web apps is just a static resource like images. So when you load a web app, you fetch the HTML (that defines the layouts basically) together with all assets linked and the browser starts executing the JS code. But the data themselves are fetched into the app in the form of JSON and then inserted into the document via templating.
For example, an email web app, when you log into it, fetches you the all HTML of all the UI, but the emails themselves come in via AJAX and JSON and injected into the DOM by JS code.
Nicely spotted! Although we're supposed to think of "global" variables as Badβ’, I think there's a definite case to be made why this is actually Not So Badβ’.
An DOM element with an ID, by definition, can be referenced from any context. Semantically, it is pretty akin to a "global variable". Also, one of the guarantees of DOM elements with IDs is that they have a speedy lookup (O(1) if possible).
With these assumptions, it makes sense that a naive implementation would store them somewhere in the global scope. Would it have been better to store them in a member object, such as
window.elementsWithIds? Probably, but quite marginally. And as Rachel Carvalho pointed out, not necessarily worth breaking legacy applications.Great catch, though. I think all front-end developers should be aware of this, if only to avoid mind-bending bugs like the one you mentioned and to understand the inner workings of the target machine (aka "The Browser").
--
EDIT: I'm quite new at Javascript so I'm bound to make some errors.
My previous argument doesn't hold in face of this little snippet.
Naming your element after a built-in
Windowproperty does not overwrite the property, but you can still perform a lookup by ID on thedocument. So there's obviously a better mechanism already in place.The fact that IDs create global objects is probably only to maintain backwards compatibility, as Rachel pointed out.
Dom elements referenced by ID are global variables and have the same drawbacks as other global variables. I've seen more than supposedly 'reuseable component' break as soon as you tried to add a second instance of it to a page because it's referencing its internal DOM elements by ID...
This is old as hell... also this is the reason why you should not define an ID for styling instead of a class for elements which you will never reffrrence. Using more unnecessary IDs spends more RAM and makes your source less optimised and less performant.
I agree that you shouldn't have variables referenced to the ID in the HTML, while from my past experience when you work on more massive/complex apps it turns up that NO IDs are the best IDs. But from what you had mentioned in the post, we have Angular 2+ template reference variables which are pretty much following the same practice as ID to window.variable just in a scope of a component.
Erm, you realise that you're talking about scoped variables, right? The very opposite of global variablesβ¦
Yup that is why I had mentioned that they are following the practice of how ID generate variables (as globals) to document, just here in the scope of the components.
The point was if you don't check the template for IDs (assuming those global vars will be used in code) , you will find them used but never defined in the JS part which might get you confused at start. While the same thing in Angular, if you don't check the template, you can find variables in your component which aren't defined there. In both cases you will have to look in the template to find the references.
I hope it is more clear now :)
Not really. In standard HTML, id attributes are made into global variables. In angular, component-scoped variables in the typescript/JavaScript are made available to the template HTML via template directives. They're two completely different things.
I knew about this for years, didn't realize it wasn't common knowledge.
Didn't know Chrome returns an array until your article.
That is what's truly insane. They literally added extra logic to process invalid HTML differently, instead of assuming valid HTML and bailing after first match.
Which means that doing
new Vue({el: app})new Vue({el: '#app'})will suddenly start failing (and only in Chrome) when someone makes an inner component that has an unfortunate#appid as well.Did a random benchmark, link to benchmark
and the result is,
Hi,
I studied this behavior on my blog, if you're interested:
xem.github.io/articles/#implicitge...
People who have had contact with front-end code for long enough will remember that this is how people used to write Javascript π€’. I'm talking about way back when websites were developed for IE 6 and did not run well on the new Firefox browser because of so much non standard html, css and js there was.
This is specified the WHATWG spec, html.spec.whatwg.org/#named-access...
Note that they explicitly point out that this is a bad idea to use in your code:
As someone who's been doing web development from the beginning of browsers, this isn't a surprise, as that's how it was done, and HTML is very backwards compatible. But what I didn't know (because I've long since stopped using this 'feature') is how Chrome treats elements with the same ID! Wow, that's weird. I just checked, and it returns an HTMLCollection, which is array-like, but not actually an array. And according to the MDN docs, Opera (I assume the old one) returns a NodeList.
I guess the different implementations is a good thing - if browser engines all acted the same, developers would end up using this old method regularly, but as it is, the best way to be cross-browser is by using an explicit getElementById instead.