5 ms·

[Slightly off topic] One of the reasons I wouldn't use ID's is because the DOM element with that ID is automatically introduced to the global scope. Open up th

by _RPM 12y ago

[Slightly off topic] One of the reasons I wouldn't use ID's is because the DOM element with that ID is automatically introduced to the global scope. Open up the console and type "up_8630368" and you will see it yields a DOM Element.

fla 12y ago
Upvoted with : up_8630835.click()
- thisGuysAccount 12y ago
  same to you, in Firefox.
paulojreis 12y ago
Is this true? If I have a element with id="foo", then "foo" will be available as a variable in the global JS context? I tried, but can't reproduce it (Chrome, Windows & Safari, OS X).
- paulojreis 12y ago
  OK, sorry about the reply to myself, but it is true indeed. I was testing with an id which contains a "-" (hyphen). As the hyphen isn't valid for a variable, you can't access it directly or via the window object (with the "dot" notation). However, it is there, and you can access it with the array-like syntax. Is this part of the spec? Or creative interpretations? tl;dr: HTML element with id="foo-bar". You can't access it as the variable foo-bar in the global context or window.foo-bar (invalid var name). However, you can access it via window['foo-bar'].
  - nailer 12y ago
    I've been told it's unspecified, but IE implemented it. and when when IE was the most popular browser, other browsers replicated the behaviour as some sites were using it in their JS - as a kind of quick shortcut for document.getElementByID. Don't have a reference though.
  - gsnedders 12y ago
    That's per spec. Because the global object can be accessed as window (and several other things…), these global "variables" are therefore merely properties on the window object. It's worthwhile to point out that foo["bar"] and foo.bar are entirely equivalent in ES5 — just the former syntax allows more properties to be expressed as it allows an arbitrary string.
  - bzbarsky 12y ago
    It started as creative interpretations, then got added to every browser except Firefox , then got added to Firefox because too many websites were relying on it. And now it's in the spec, because too many sites are relying on it, so a browser that doesn't do it wouldn't be web-compatible. Classic race to the bottom. :(
- cesarb 12y ago
  Seems to be true: https://html.spec.whatwg.org/multipage/browsers.html#named-access-on-the-window-object https://html.spec.whatwg.org/multipage/browsers.html#named-a...
pmontra 12y ago
It's the DOM element to upvote this whole post at the top of the page. I agree that polluting JavaScript's global space is bad. I wonder if this could be a vector for some attack. Probably not because it would be well known for a long while (but I didn't know about it untile 5 minutes ago, thanks).
- Lambdanaut 12y ago
  It seems like you'd need to inject malicious Javascript into the page before you could run an attack like this. General XSS attacks would be the larger, encompassing vulnerability.
  - nitrogen 12y ago
    It seems malicious HTML could do it, too, if the global element variable replaces some other global object of the same name.
- Ded7xSEoPKYNsDd 12y ago
  Just recently I saw this used to make a script fail at a very specific point. A script running later expected the first one to have run successfully, opening up an attack vector that works even with CSP in place. The full story is here: https://github.com/ctfs/write-ups/tree/master/hack-lu-ctf-2014/hotcows-dating https://github.com/ctfs/write-ups/tree/master/hack-lu-ctf-20...
untog 12y ago
I get that being annoying, but is it really that big of a deal?
- _RPM 12y ago
  I don't think it is a big deal. It is just slightly arbitrary, in my opinion.
- nailer 12y ago
  In my personal experience, yes. I first found out about it when it broke something. I was using fineuploader, since there was only one element which used fileuploader, it was #fineuploader, and since fineuploader wasn't an AMD module, it exported window.fineuploader() which got blatted by the element.
arenaninja 12y ago
Wow, today I learned. I've seen iffy situations with name attributes in IE before, I had no idea that IDs became globals... I can't wait for it to bite me
josephscott 12y ago
I did not know this before, very interesting. Despite the easy access as a global variable, using document.getElementById() turns out to still be faster - http://jsperf.com/id-vs-class-vs-tag-selectors/328 http://jsperf.com/id-vs-class-vs-tag-selectors/328

by _RPM 12y ago

fla 12y ago

Upvoted with : up_8630835.click()

thisGuysAccount 12y ago
same to you, in Firefox.

paulojreis 12y ago

Is this true? If I have a element with id="foo", then "foo" will be available as a variable in the global JS context? I tried, but can't reproduce it (Chrome, Windows & Safari, OS X).

paulojreis 12y ago
OK, sorry about the reply to myself, but it is true indeed. I was testing with an id which contains a "-" (hyphen). As the hyphen isn't valid for a variable, you can't access it directly or via the window object (with the "dot" notation). However, it is there, and you can access it with the array-like syntax. Is this part of the spec? Or creative interpretations? tl;dr: HTML element with id="foo-bar". You can't access it as the variable foo-bar in the global context or window.foo-bar (invalid var name). However, you can access it via window['foo-bar'].
- nailer 12y ago
  I've been told it's unspecified, but IE implemented it. and when when IE was the most popular browser, other browsers replicated the behaviour as some sites were using it in their JS - as a kind of quick shortcut for document.getElementByID. Don't have a reference though.
- gsnedders 12y ago
  That's per spec. Because the global object can be accessed as window (and several other things…), these global "variables" are therefore merely properties on the window object. It's worthwhile to point out that foo["bar"] and foo.bar are entirely equivalent in ES5 — just the former syntax allows more properties to be expressed as it allows an arbitrary string.
- bzbarsky 12y ago
  It started as creative interpretations, then got added to every browser except Firefox , then got added to Firefox because too many websites were relying on it. And now it's in the spec, because too many sites are relying on it, so a browser that doesn't do it wouldn't be web-compatible. Classic race to the bottom. :(
cesarb 12y ago
Seems to be true: https://html.spec.whatwg.org/multipage/browsers.html#named-access-on-the-window-object https://html.spec.whatwg.org/multipage/browsers.html#named-a...

pmontra 12y ago

It's the DOM element to upvote this whole post at the top of the page. I agree that polluting JavaScript's global space is bad. I wonder if this could be a vector for some attack. Probably not because it would be well known for a long while (but I didn't know about it untile 5 minutes ago, thanks).

Lambdanaut 12y ago
It seems like you'd need to inject malicious Javascript into the page before you could run an attack like this. General XSS attacks would be the larger, encompassing vulnerability.
- nitrogen 12y ago
  It seems malicious HTML could do it, too, if the global element variable replaces some other global object of the same name.
Ded7xSEoPKYNsDd 12y ago
Just recently I saw this used to make a script fail at a very specific point. A script running later expected the first one to have run successfully, opening up an attack vector that works even with CSP in place. The full story is here: https://github.com/ctfs/write-ups/tree/master/hack-lu-ctf-2014/hotcows-dating https://github.com/ctfs/write-ups/tree/master/hack-lu-ctf-20...

untog 12y ago

I get that being annoying, but is it really that big of a deal?

_RPM 12y ago
I don't think it is a big deal. It is just slightly arbitrary, in my opinion.
nailer 12y ago
In my personal experience, yes. I first found out about it when it broke something. I was using fineuploader, since there was only one element which used fileuploader, it was #fineuploader, and since fineuploader wasn't an AMD module, it exported window.fineuploader() which got blatted by the element.

arenaninja 12y ago

Wow, today I learned. I've seen iffy situations with name attributes in IE before, I had no idea that IDs became globals... I can't wait for it to bite me

josephscott 12y ago

I did not know this before, very interesting. Despite the easy access as a global variable, using document.getElementById() turns out to still be faster - http://jsperf.com/id-vs-class-vs-tag-selectors/328 http://jsperf.com/id-vs-class-vs-tag-selectors/328