Just to say this has been filed in Lighthouse and I will look into it. I disagree with Sandy that this is Microsoft's 'fault' - this is the problem we are always open to when we extend native prototypes. I am a lot of experience in C#/.NET programming so this is something I have a vested interest in. I don't believe it to be an insurmountable problem.
On Dec 19 2009, 7:17 am, Sanford Whiteman <sa...@cypressintegrated.com> wrote: > > The reason this is occurring is because in the mootools framework(core) it > > defines it defines a function off of document called id.. open up your core > > file and search for "id:(function()" you will notice that it is grouped by > > several other handy sounding functions.. it just a shortcut to > > document.getElementById.. > > Surely anyone who uses the latest Moo knows about this function. > > http://mootools.net/blog/2009/06/22/the-dollar-safe-mode/ > > > So why does .net get tangled up in this? because when a click event occurs > > anywhere on the page, .net is enumerating elements looking for particular > > ones in a list it keeps... and it looks at element.id (as you would expect > > to look for an id of an element) > > document.id != Element.id > > The bug is in Microsoft's code, where they frequently have a var named > `element` actually be set to either an Element object or to document. > (While document.documentElement is an Element, document by itself is > not.) They are stupidly duck-typing `element`, relying on `element.id` > == undefined whenever element is really a document and thus gracefully > avoiding some code sections. > > When `element.id` turns out to exist even when element = document, > they have a problem. They wouldn't have this problem if they just > checked the type of `element`, which in turn would be easier if they > used a not-completely-misleading variable name. > > > So what do you do? > > Stop blaming MooTools and dare to report/bugfix theMScode instead? > > -- Sandy
