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.


  • How will IE7 affect this?

  • onload may not work in Safari, but you can certainly use dynamic script insertion, where the way you are "notified" is that your script runs. Combine this with a JSONP-style callback and you are golden.

  • But isn't the benefit of using the "detect capabilities" approach that when browsers will implement said capabilities your library will automatically work without you having to do any work to it?

    Writing to capabilities seem to make more sense then writing to browsers as browsers change but capabilities won't (unless they get respecifieid of course).

    Also you say about detecting capabilities:

    Adding a new browser means touching all of the code base.

    But if you write to capabilities it means it's browser independent, you don't have to add a new browser? I'm probably not understanding your argumentation fully but would be interested in hearing more about it. Thanks :)

  • How about support of IE's event model?Is there onfocusout/onmouseenter/onmouseleave support in firefox?


  • Andrey: there is support for the IE event model in general (attachEvent, detachEvent, window.event, etc.) but not for specific events for the moment. We may add these in the future if there's enough demand for it.

  • I really think you made the wrong decision with the compat layer and all the window.event stuff.

    If you're not going to adhere to standards, and you're creating such a rich, proprietary javascript API anyway, then why not have a new function for observing events like the Prototype Framework does with Event.observe()?

    Basically you're asking developers to learn a beautiful library which introduces things like inheritance, Atlas XML script, etc. Asking developers to learn two new functions: observe() and stopObserving(), for example, would be extremely trivial.

    Also, I think your worry about changing the entire code-base upon introduction of a new browser is unwarrented. A properly engineered system can simply provide self-registering strategies which would require no change to the code-base, only a new strategy file.


    //expose some function like:
    Atlas.MapEventModel( browserEventStrategy ){}

    Assuming that each browser/compatibility strategy implements the proper contract, all the functionality needed to map DOM events to the Atlas framework would be taken care of compositionally in an extensible and maintainable manner.

    As it is now, you're claiming that the reason you implmented the compat layer the way you did is because other browsers are extensible in ways IE isn't. This implies the assumption that any new browser that comes out will be as extensible as the rest which is very very dangerous. What if a browser comes out that doesn't allow you to hook up window.event? It's very possible!

    The suggested alternative, on the other hand, is more likely to be able to work around the quirks of browser/capability event incompatibilities present and future. Event handling would happen through a consistant interface that is easy to learn, and the underlying details of providing the mapping to the consistent interface would be properly encapsulated into files such that each are independently updatable and easy to introduce as new browsers with different capabilities come along.

  • Colin: these are great points. We had arrived to the same conclusion about the extensibility of the model. The new solution we're developing is more conventional and won't perform as well, but it will be easier to add new browsers even if they don't provide good extensibility points.
    Fortunately, Atlas did not ship yet, so we can still take user feedback into account and revise what seemed to be good decisions at the time.

  • That's very good to hear!

    I'm consistently impressed by the overall coolness of Atlas and am excited to see it grow. There are a few kinks to work out, but I have no doubt the Atlas client libraries will eventually wipe the floor with other AJAX/JavaScript frameworks.

  • Dear freinds,
    I have a web application developed in vb.net. I use
    Atlas Timer control to update my update panel . This application working fine on internet explorer but not envoking timer in fire fox... any buddy hving clue kindly help me

  • Ali: please contact me through the contact form of this blog.

Comments have been disabled for this content.