Hacker News Reader

Comment by gruseom | Hacker News Reader

We must be talking about slightly different things. Here's what I do, which works fine in IE6 and 7:

  <div id="bob">...</div>
  <script>var bob = $('bob');</script>

Seems almost identical to the code in the post (mine says "var" and his doesn't, mine uses $ to get element by id, his uses a 'get' function that presumably does the same thing). It does not produce an 'object undefined' error (or any error that I've seen).

By "it works fine" I mean that the variable bob references the appropriate DOM element and behaves as expected.

What should I change in the above to reproduce this error?

View on HN

The reason that code works is because in IE you're not actually doing anything. All elements with IDs are already in the global scope.

var bob = $('bob'); is a useless statement in IE.

The issue comes when you do something more like this.

now bob doesn't equal "hello world". Your global has been clobbered.

---

Similarly, it's surprising how many people fall into this trap:

Well that's all great and everything, but you've just clobbered the submit() function on the form.

before:

form.submit = function()

now:

form.submit = Your dumb input element.

This explanation makes sense, but I can't reproduce the behavior.

in IE ... all elements with IDs are already in the global scope

This I can confirm. If the page contains this:

  <div id="bob">Hi</div>

then the following evaluates to true in IE:

  bob == $("bob")

...without defining the variable. I didn't know that - thanks!

The issue comes when you do something more like this.

  <script> var bob = "hello world"; </script> <div id="bob">Hi</div>

now bob doesn't equal "hello world". Your global has been clobbered.

One might expect this, given the above, but I tried it in both IE6 and IE7 and the global keeps the value it had before.

OK It's been a while. It may only happen when you start modifying the dom, or using innerHTML.

End of the day though it's a bad idea and at some point you'll clobber variables you didn't want to.

the problem arises when you try to directly access the element with id="bob" e.g. bob.innerHTML this will work on explorer

and is called global namespace polluting. and it could get things mixed up. So, a good practise is not to name DOM elements with javascript variables.

The reason you never ran into the problem is because that locally you create a variable with a reference to the DOM element, so you are practising a "workaround"

Actually, I'd argue that relying on magical global variables mapping to page elements is bad practice in the first place.

If you want an element by ID, that's what document.getElementByID is for (or $ if you're using a JS framework). If you want a form element by its name (why not it's id?), you should go out to get that specifically.

My JS is compiled from higher-level source; at the source level there is no duplication and it's simpler to use a variable. Moroever, using getElementById is 60% slower than a global variable in FF and more than 10x slower in IE. For the app I'm building, this matters a lot.

Of course it's faster to use a precomputed reference than to find an element in the DOM. I can't see the "overhead" of manually storing a reference to a DOM element in a variable ever mattering in any application. Grab it once and you're done.

the only sure thing is that the whole javascript perfomance/memory footprint/cross-browser/degrade challenge can drive someone crazy!

I'm afraid I don't follow. Creating a variable that references a DOM element (whose ID equals the variable name) is not a "workaround", it's the thing that's supposed to produce an error in IE. I'm not seeing that error. What do I need to change in what I described above in order to produce it?

See my post above for an example of an error that arises from this.

Reply on news.ycombinator.com