To harness or exploit the most out of CSS classes is to take advantage of what truly is the unsung hero of advanced RIA development as it relates to the presentation layer. When we observe our markup, we find that various portions of the DOM may require styling influences on the initial page load as well as interaction events or cues to adjust its structure, positioning, visibility, state, and skin. For this classes are the clear suitor, as it brings flexibility, modularity, inheritance, and a dynamic and unobtrusive nature to the table.

It has by far been the most popular thing to come out of this blog since its inception, and I am very proud to officially release version 2, and this time I’ve included all the bells and whistles you’ve been asking for! The framework now boasts support for an impressive amount of transitions, CSS multi-unit support (em, %, ex, and all the rest), and many more optimizations for increased performance to get those smooth animations we all want.

If you have ever wanted to manipulate those brand spanking new styles such as -moz-transform, -webkit-transition, or even some older ones like opacity in IE and max-width in IE6 but didn’t because you were reluctant of browser support, than you are not alone. For this article, I will be exploring some unique tactics in an effort to solve the dilemma as it relates to JavaScript.

It is still a controversial issue today despite the recent evolutions in the industry including new modern browsers and new resources such as jQuery (as of version 1.3) that now entirely base their implementations on feature testing. However, somehow the practice of browser detection seems to still be alive and well, whether it be new browsers bringing about new bugs, features that are difficult to detect, or simply shortcuts spawned out of pure laziness, the practice is not only being used but defended. Browser sniffing can be found around just about every corner you look – from the smallest of websites, to your favourite JavaScript library (Mootools, Prototype, YUI, etc.) utilized in corporate giants such as Chrysler, Gamespot, and Yahoo!

It is rarely even a question anymore; deciding whether to use a JavaScript library on your next project typically goes without saying, the real question developers find themselves asking is which library should it be? However the decision to adopt any framework for a project should not be taken lightly and deserves a proper evaluation of requirements before making a decision based on assumptions. Often a library may ask of a developer, “Does the JavaScript library help me to write JavaScript?”, but shouldn’t they ask if the library helps them to learn JavaScript? Learning the syntax of your favourite JavaScript library does nothing for the developer’s understanding of the language itself or the impact on performance, memory, and reliability of their implementations. For this article, I will be looking at both sides of the argument, but hiding my bias will not be easy, my hope here is that perhaps a few developer’s may rethink their approach.

Scope or context as it is often referred to as is one of the fundamental aspects of Javascript, playing a significant role unlike that of any other language. Scope refers to the accessibility of variables and its execution context which belongs to the object or function in which it was defined. However this does not always hold true as scope can be lost or changed depending on how and where it used, specifically as it applies to functional execution.

Its one of those unnecessary things, but it sure does look pretty, I’m of course talking about animation. Flash or Javascript based, I find it adds that little some extra for the end-user’s experience; allowing them to fully understand the actions taking place by visually seeing components in transition. Most all mainstream libraries support animation in one way or another, and they are all quite impressive, despite the fact the core of each library essentially works the same.

For the most part, I’ve typically relied on window.onload for my various projects; its simple, cross-browser, and the alternative onDOMReady functions were unreliable due to their utilization of browser sniffing in some fashion. However, the problem with window.onload, as I’m sure you’re all aware, is that it doesn’t fire until the entire page has loaded including all images. This can make for a usability nightmare for any page with a lot of images and/or anybody with a slow connection. If your page relies on JavaScript then there could very well be an extended amount of time whereby the user is interacting with the page and it hasn’t yet been initialized. An onDOMReady-related function is the more modern approach, allowing you to define a function that will execute as soon as the DOM is in a usable state, that is to say structurally complete. The main obstacle now is to create a solution that is not dependent on browser detection.

There is something inherently powerful about what direct data interaction and manipulation is capable of and the ease at which it performs. XSLT may be called a stylesheet but it is nothing like CSS, it deals directly in data management and presentation, utilizing advanced functionality typically reserved for a scripting language. Similar to what Smarty is to PHP templates, XSLT basically defines the rules for rendering an XML file, with one important distinction – the data is live. The data is subject to further XSL manipulation after the XML document has been initially transformed, facilitating many dynamic features. This has great implications on the web applications of the future; loading a widget could be as simple as dynamically loading an XML document which contains all settings and instructions, performing an XSLT transformation and appending the result document to the DOM. With those kind of capabilities the potential for such an application is limitless.

Here I will not only be sharing the latest news, resources, tutorials, and tools but it will also serve as a platform. As a long time supporter and beneficiary of the open source community, I figured it was time to give back. The main focus of my projects will be to fill a certain niche market of open source Javascript, that being library independent and free of browser detection.

You see I have a problem with Javascript libraries in general, it has always been my contention that each project deserves its own library containing only required modules. The facilitation of browser sniffing is just the icing on the cake; more often than not I find it a simple means to an end or an unnecessary shortcut, all you have to do is view the source of some of the most popular Javascript libraries to see examples of this. A solution short of checking the user agent is often easier than one might have thought.

In that spirit, I will be releasing various modules that promise to be lightweight, standalone, cross-browser, and contain no browser sniffing whatsoever. Be warned, I don’t like rewarding or encouraging bad programming, so don’t expect me to support your mistakes; if your working without a doctype, that is your problem!

I look foward to future dialog.