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?
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"