4

Can someone tell me the difference between calling an HTML elment with id="myDomObect"?:

var myObj = document.getElementById('myDomObect');

&

var myObj = myDomObect;
user2864740
  • 60,010
  • 15
  • 145
  • 220
BeachInCalifornia.com
  • 179
  • 1
  • 9
  • the first is more formal (standard) while I remembered that some old version of some old browser does not support the second. – King King Oct 13 '14 at 01:56
  • IE has long supported name and ID as globals, everyone else caught up to this a few years back. it's one of the few good parts of IE that got universally adopted before IE's special tricks went away (innerHTML, and outerHTML being the other) – dandavis Oct 13 '14 at 02:00
  • 1
    FWIW, while innerHTML **was** a good part of IE that got copied this is a **very bad part** that got copied. – slebetman Oct 13 '14 at 02:13
  • i use it all the time in devtools to save typing, which alone makes it worth including... – dandavis Oct 13 '14 at 02:16
  • 1
    possible duplicate of [Do DOM tree elements with ids become global variables?](http://stackoverflow.com/questions/3434278/do-dom-tree-elements-with-ids-become-global-variables) – user2864740 Oct 13 '14 at 02:21
  • 1
    good points (relative to this over-blown issue) on http://stackoverflow.com/questions/25325221/why-dont-we-just-use-element-ids-as-identifiers-in-javascript... – dandavis Oct 13 '14 at 02:23
  • if you want to rely on this behavior in real-world code, at least make it robust: [].slice.call(document.querySelectorAll("[id]")).reverse().forEach(function(a){window[a.id]=a;}); – dandavis Oct 13 '14 at 02:29

2 Answers2

8

Use the first form or a wrapper such as jQuery. The second form,

var myObj = myDomObect;

Translates to

var myObj = window["myDomObect"];

This "works" because of an old, old hack in which ID's were exposed as global window properties (IIRC this was a misfeature from the start) and thus we are still blessed with the behavior 20 years later.. and yes, it will work in the very latest Chrome.

However, such a shorthand should not be used for multiple reasons:

  1. It will not work as originally written in "strict mode" (but it will work with the second form)

  2. It does not convey the operation - namely that a DOM element is requested/fetched (by ID).

  3. It does not work for IDs that collide with window properties; eg. <div id=history></div> would result in "unexpected behavior" if accessed this way. (This doesn't affect getElementById code that correctly uses local var variables in a function.)

  4. Behavior is not defined when duplicate IDs exist in the document (which is allowed); the behavior for getElementById has been codified in by DOM 4: "getElementById(elementId) method must return the first element [with the ID], in tree order.."

See also:

Community
  • 1
  • 1
user2864740
  • 60,010
  • 15
  • 145
  • 220
1

The first is how the "real" DOM API works (another option is document.querySelector("#myDomObject")). The second is how browsers have started implementing automatic hoisting of id'd elements, since ids are supposed to be unique. In a twist of "what were you thinking", this can lead to hilarious conflicts where variables that have the same name as HTML elements with an id don't take precedence and the variable you though you were using is suddenly an HTML element.

Mike 'Pomax' Kamermans
  • 49,297
  • 16
  • 112
  • 153
  • that can't happen, any local or global variable gets in front of the element, which is the part that most folks complain about. – dandavis Oct 13 '14 at 01:59
  • you'd think, wouldn't you? Turns out the way it was implemented in Chromium frequently let this happen anyway. – Mike 'Pomax' Kamermans Oct 13 '14 at 01:59
  • "was" as in "no longer", or as in "how it got the way it is now" ? – dandavis Oct 13 '14 at 02:01
  • I haven't tried in recent weeks, but I ran into it a few months ago, so it could still be the case, it could be fixed, but it's worth bearing in mind that this is not standard DOM spec and can create odd code behaviour. – Mike 'Pomax' Kamermans Oct 13 '14 at 02:15
  • Why is HTML5 not a standard dom spec? http://www.w3.org/TR/2011/WD-html5-20110525/browsers.html#named-access-on-the-window-object – dandavis Oct 13 '14 at 02:18
  • which one do you want, the w3c one or the whatwg one? Multiple specs, and as "user2864740" points out, a backward compatibility hack. It's not "standard" in that it's really fricking weird behaviour (IE, for all its flaws, thankfully doesn't support it), and is only there because legacy keeps forcing it in. – Mike 'Pomax' Kamermans Oct 13 '14 at 02:19
  • they both define window[elm.id] behavior. they both complain about it too. ;) – dandavis Oct 13 '14 at 02:21