Let me explain one more time why the Atlas compatibility layer works this way...
It's the second time in just a few days that I see blog comments attack Atlas on its compatibility layer. I've tried to explain a few days ago why we made this design choice but I think it deserves an even more detailed explanation...
There are basically three ways you can make a library cross-browser.
- You can detect capabilities every time you need them. If you do that, all new code must take all browsers into account. Adding a new browser means touching all of the code base.
- You can write an abstraction layer that creates another API that abstracts the concrete APIs of each browser. This is no more standard than the other two ways as you're really introducing a new proprietary API on top of the existing standard and proprietary ones.
Furthermore, this is making the code path longer as each use of the API must go through an additional function call and must redo the capability check every time it's called. - Finally, and this is what Atlas is doing, you can extend one or several of the browsers to make all browsers consistently callable. In this case, the code path is the most direct and the capability detection happens only one time, when the compatibility layer is created. An additional advantage of this technique is that you can add a new browser by simply writing its compatibility layer, without having to touch the actual library.
Now, why did we extend Firefox and Safari and not IE? Simply because Firefox and in a lesser extent Safari are far more extensible than IE. For example, you can modify the prototype of HTML elements and thus act once to extend all instances of all elements. Firefox goes even further by allowing the definition of getters and setters for element properties. If IE had the same extensibility, we would happily have made it converge to the standard instead of bringing Firefox and Safari to implement the IEisms. We would have absolutely loved that but it's simply not possible.
There is no malice there, purely technical reasons.
Furthermore, let me point something out. It's very well that Safari and Firefox follow the standards when they exist and I'm glad they do but it's not enough for Ajax applications because they *all* rely on non-standard capabilities. XmlHttp is not a standard for example.
Here's another example where despite its excellent adherence to standards, Safari is making things difficult: how do you dynamically load arbitrary script and get notified when the script is done loading? Well, Safari has only recently implemented dynamic script loading but as far as I know (and the documentation is far from sufficient on this subject) there is no way you can get notified when it's done.