> It's the way IE builds the dom for its browser and it actually isnt
> compliant anyway. I would "never" reference anything in the dom like that
To me, the danger is not in never referencing things like that but
rather, not defining / setting variables due to IE defining it for you.
for example, relying on a global variable being set to do something or
not...
if (!window.divNoNeedForDollarSign)
window.divNoNeedForDollarSign = "foo";
alert($type(window.divNoNeedForDollarSign));
-> Element, not string.
even though due to hoisting and lack of block scope in javascript, doing
if (cond)
var divNoNeedForDollarSign = 'foo';
actually results in:
var divNoNeedForDollarSign;
if (cond)
divNoNeedForDollarSign = 'foo';
and this declarative behaviour seems to override the export from the DOM.
i have seen some bizare cases where element ids / names have spilled
into js and caused behaviour that is really difficult to fix...
All of that is to be expected but what i really have a problem with is, chrome
currying this over though, makes no sense. Code that relies on such
practice should just break and rightly so.
Best regards,
--
Dimitar Christoff <[email protected]>
blog: http://fragged.org/ twitter: http://twitter.com/D_mitar
