Benefits

One benefit in particular is in a nodes ability to support multiple class declarations at a time, which in a sense facilitates a multiple inheritance of sorts. This gives us the unique ability within CSS to separate an element’s various states and differing characteristics to create a more modular approach in our stylesheets. By doing so, we can create classes that are in no way specific to any one element but merely represents a characteristic or group of characteristics that any node can adopt provided the class name.

Inheritance can also play a key role in the design process, by letting the cascade flow through the DOM we can leverage the styles of ancestor nodes and avoid a rigid implementation with redundant style declarations. If we employ this technique, we can easily alter state of descendant nodes by adding or removing a class to or from that of an ancestor node while avoiding the need to traverse the DOM to manipulate each descendant node individually in our script.

As far as client-side scripting is concerned, classes are the preferred window to CSS from JavaScript. By hiding styling characteristics behind class names, JavaScript can merely alter a node’s className attribute to activate or deactivate a specific state of that node. In this case, JavaScript is not concerned with what styling influences are taking place on page load or even after event triggered changes in state. This allows us to quickly consult our CSS to make minor styling changes rather than JavaScript.

Abstract Classes

Abstract classes are those that do not necessarily reflect a state or any specific node but common characteristics shared between nodes of varying purpose and context. Take for instance the following:

.widget {
    font-family: Trebuchet MS, Tahoma, Verdana, Arial, sans-serif;
    font-size: 1.1em;
}
 
.overlay {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}
 
.content {
    display: block;
    -khtml-box-sizing: content-box;
    -webkit-box-sizing: content-box;
    -moz-box-sizing: content-box;
    -ms-box-sizing: content-box;
    -o-box-sizing: content-box;
    box-sizing: content-box;
    zoom: 1;
}

As you can see these examples are of a very generic nature both in name and styling influences as they represent a very high level abstraction. Typically classes such as these should always be combined with others as part of a node’s class declaration to round out its structure, positioning, state, and skin.

The advantage of abstract classes do not come solely in their ability to apply styles to a node in a modular fashion, but also in the relationships they create. Think of it from the perspective of object-oriented programming, provided the overlay class, a node will inherit the role of an overlay. For example:

<div class="widget">
    <div class="overlay widget">
        <!-- widget markup -->
    </div>
</div>

In this case, the parent node is a widget and has a widget and has a overlay while the child node is a widget and is a overlay. Although the child node is both an overlay and a widget, it is important to recognize that this node can be referenced by either statement together or independently of the other, like so:

.widget .overlay {
    /* target overlays that belong to widgets */
}
 
.widget .widget {
    /* target widgets that belong to widgets */
}
 
.widget .widget.overlay {
    /* target overlays that are also widgets that belong to widgets */
}

By grouping nodes together in this manner we can target nodes based on their role, state, structure, positioning, document position, or relativity to other nodes. From here we let inheritance fill in the gaps; as we move further down the DOM hierarchy the more precise and relevant our styles become to the specific nodes to which they are applied. Width and height, for example, should typically be reserved for styling in a low level context, while font (family, size, and color) is best served at a high level. Not to mention that this grouping makes it very easy for JavaScript to quickly reference or query for various nodes in various contexts for fast and easy manipulation.

Character Classes

Similar to abstract classes, character classes work on a lower level context and are designed to fulfil one purpose relating to a characteristic or group of characteristics. They help to achieve both visual and cross-browser consistency across an application in the purpose that they serve. For example, the following are some character classes of varying purposes:

.hidden {
    display: none;
}
 
.float-left {
    float: left;
    display: inline;
}
 
.center {
    margin-left: auto;
    margin-right: auto;
}
 
.text-overflow {
    width: 100%;
    text-overflow: ellipsis;
    -o-text-overflow: ellipsis;
    white-space: nowrap;
    overflow: hidden;
}

Typically character classes do not need to be overridden in a lower level context as they should be mutually exclusive from your structure and skin. You’ll also want to avoid depending on character classes to target descendants as part of a selector statement. Doing so will expand the scope of the class beyond its original purpose, this can snow ball into further dependencies that result in a loss of modularity and flexibility.

Exploiting character classes to the fullest means easy adoption of shared markup conventions and allow for ease in code integration. By putting together a small component library, you will find that they will not only provide reusable classes throughout an entire application but also amongst projects.

Themed Classes

As you might have guessed, themed classes have everything to do with your skin, this means fonts, colors, background images, formatting, icons, and states. Take for instance the following:

.loading {
    cursor: wait;
}
 
.active {
    border: 1px solid #327E04;
    background: transparent url(active-state.png) 50% 50% repeat-x;
    font-weight: normal;
    color: #ffffff;
    outline: none;
}
 
.disabled {
    cursor: not-allowed;
    -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=60)";
    filter: alpha(opacity=60);
    opacity: 0.6;
    -moz-user-input: disabled;
    -moz-user-focus: ignore;
    -moz-user-modifty: read-only;
    -khtml-user-modify: read-only;
    -webkit-user-modify: read-only;
}

Classes such as these are most useful for when theming various user interface widgets. We can use a group of semantic presentation classes to indicate the state of a widget such as default, hover, active, and disabled. As the user interacts with the page, we dynamically apply the appropriate class to the widget to represent its current state. This level of class consistency makes it easy to ensure that all nodes with a similar role or state will look the same across all widgets.

Like abstract classes, themed classes also create relationships, however these relationships are more targeted towards a node’s state as opposed to its role. This makes it simple to target nodes based on their current state, for instance active nodes:

.overlay.active .header {
    /* target the header of active overlays */
}
.overlay.active .body {
    /* target the body of active overlays */
}

Here we can add additional rules to automatically style the descendants of a node based on its state without directly referencing the descendants in CSS via additional class names or in JavaScript via DOM traversal.

Progressive enhancement also falls under the cloud of themed classes as it can be utilized to bring greater aesthetics to your skin. It differs in the sense that a class will be responsible for providing a single detail (rounded corners, drop shadow, gradient backgrounds, etc.) to the theme in a cross-browser and consistent manner:

.shadow {
    -khtml-box-shadow: 0px 0px 10px rgba(0, 0, 0, 0.5);
    -webkit-box-shadow: 0px 0px 10px rgba(0, 0, 0, 0.5);
    -moz-box-shadow: 0px 0px 10px rgba(0, 0, 0, 0.5);
    box-shadow: 0px 0px 10px rgba(0, 0, 0, 0.5);
}
 
.corners {
    -khtml-border-radius: 5px;
    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    border-radius: 5px;
}

By grouping vendor specific styles together (-webkit-, -moz-, -o-, -ms-) nodes will adopt the behaviour in supported browsers and degrade gracefully in unsupported browsers. This helps to keep code not only backwards compatible but also future proof:

If properly implemented we can achieve visual consistency across an application and allow components to be themeable in a rather simplied and modular fashion.

Summary

When we combine all these techniques, we find utter simplicity in forming both the structure and skin of a node, while minimizing the amount of node specific style declarations in our stylesheet. If done right, you will find your markup will greatly improve as a result and it will be as easy to write as the following:

<div class="widget overlay corners shadow active">
    <div class="header content">
        <!-- header markup -->
    </div>
    <div class="body content">
        <!-- body markup -->
    </div>
    <div class="footer content">
        <!-- footer markup -->
    </div>
</div>

These techniques help to serve as an advantage not only to your CSS but also your markup and JavaScript for a truly unobtrusive implementation. To learn more techniques or to read further on a few I’ve discussed here, please refer to Nicole Sullivan’s OOCSS (Object-Oriented CSS) project, it is truly a great read and highly recommended.

How to Use?

Not much has changed in the way of syntax from the previous version. The first argument accepts either the id of the element you wish to animate or the element itself. The second argument specifies the attributes of the animation, by defining the style and an ending value (“to”) and optionally a starting value (“from”) which otherwise defaults to the elements currently computed style:

var fx = new FX(el, {
    'font-size': {to: 14},
    'background-color': {from: 'FF0000', to: '0000FF'}
});

Additionally, you can optionally specify a duration (defaults to 0.7 seconds) as the third argument, the transition (brand new) as the fourth argument, and finally a callback method and the context you wish to execute the callback in as the fifth and sixth parameters:

var fx = new FX('element', {
    top: {to: 200},
    left: {to: 200},
    width: {from: 100, to: 200},
    height: {from: 100, to: 200}
}, 1.3, 'easeOut', callback, this);

The only method you need to concern yourself with is the start method, which starts the animation and requires no arguments:

var fx = new FX('element', {height: 400}});
fx.start();

That’s it! In just a couple of lines, you have the ability to animate any element any which way you want! What more could you ask for? I’d actually like to know!

CSS Multi-Unit Support

Brand new to the framework, FX now supports multiple CSS units for all scalable styles such as width and height. By defining an optional “units” property for each attribute you can specify which unit to apply to that specific style:

var fx = new FX('box', {
    width: {to: 20, units: 'em'},
    height: {to: 60, units: '%'}
});

Any and all CSS units are supported, including; em, pt, %, ex, in, mm, cm, and more. If no unit is specified for the attribute, it defaults to px.

Transitions

A feature promised and often asked for, FX now includes a much greater support for various transitional easing methods. Included in the library are your four basic transitions; linear, easeIn, easeOut, and easeInOut which is defined as an optional fourth parameter of the constructor, defaulting to easeInOut if not provided:

var fx = new FX('component', {
    opacity: {to: 1},
    left: {to: 300, units: 'ex'}
}, 1, 'easeIn');

In case that isn’t enough, you can also download the optional transitions pack, which adds an additional 30 transitions to the framework such as; quint, expo, circ, elastic, bounce, and many more!

Optimizations

Version two features over a dozen optimizations designed to improve performance, usability, browser support (still without a trace of browser sniffing), and overall efficiency. For you this means increased speed and a smoother animation.

Demo

To try an illustrative example of all the old features mixed with the new, click here. The example demonstrates multiple tweens against multiple styles using multiple units, and multiple transitions – all of which are randomly generated.

What’s Next?

The framework itself still has many different directions it can go, and I’m sure in time we’ll gain support for any and all features we’ve yet to attain. From here I hope to create additional functionality exclusively related to elements and element control, this includes animation queues, delays, and a wealth of helper methods for effects such as fading, sliding, highlighting, motion, morphing, and many more. If you have any suggestions as to what you would like to see in upcoming versions, as always, I welcome your input and look forward to supporting this framework for a long time to come.

Download

• Compressed (5kb)
• Fully Documented (10kb)

Transitions

• Compressed (4kb)
• Uncompressed (5kb)

Since browser detection is entirely unreliable and unnecessary, we need to find something better. Instead we will employ feature testing to ascertain the browser’s capability of computing the style we are trying to determine support for. The method here is simple, if the browser can interpret the style than it must be supported, otherwise it must not.

In IE we can use the little known runtimeStyle object inherit to all elements in IE, it allows us to set the cascaded style (represented in currentStyle) which will override any and all other styling influences on the element. However we won’t be using runtimeStyle to set the style, but to check the value it holds to determine whether or not the style was properly computed. By simply examining the value held for the style in the runtimeStyle object, we find that it returns undefined for unsupported styles:

typeof el.runtimeStyle.width !== 'undefined'; // true
typeof el.runtimeStyle.opacity !== 'undefined'; // false

As for any standards compliant browsers, we check for support in a similar fashion; using the getComputedStyle method we can check to see if the style is capable of being interpreted. As with runtimeStyle in IE, only unsupported styles will return a value of undefined:

typeof view.getComputedStyle(el, null).test !== 'undefined'; // false
typeof view.getComputedStyle(el, null).minWidth !== 'undefined'; // true

Thats it! When we combine these techniques we get a robust method to detect CSS style support in all the mainstream browsers. Throw in some caching for increased performance and isStyleSupported is born:

isStyleSupported = (function(){
    var cache = {};
    var el = document.createElement('div');
 
    return function(style){
        if(style in cache){
            return cache[style];
        }else{
            var supported = false;
            if(el.runtimeStyle){
                supported = typeof el.runtimeStyle[style] !== 'undefined';
            }else{
                var view = document.defaultView;
                if(view && view.getComputedStyle){
                    var cs = view.getComputedStyle(el, null)[style];
                    supported = typeof cs !== 'undefined';
                }
            }
            return cache[style] = supported;
        }
    }
})();

Perfect right? Well not so fast, we don’t have to stop there, why not extend the method to not only determine support for styles, but their assignable values? Multiple backgrounds, gradients, and the rgba specifications are just a few of the values new to CSS3 that we can leverage given a reliable test case.

Amazingly, IE again makes this quite easy using the technique we’ve already employed for determining style support. All we need to add is value assignment via the style object and wrap the test case in a try-catch block as IE will throw an error for unsupported style values.

try{
    el.style.width = '12px';
    supported = typeof el.runtimeStyle.width !== 'undefined'; // true
 
    el.style.width = 'abcd';
    supported = typeof el.runtimeStyle.width !== 'undefined'; // false
}catch(e){};

However, if we are looking to determine support for the style values in standards compliant browsers, than getComputedStyle proves to be unreliable. Take for instance any number of scalable styles such as width and height, the method will always convert any units back to pixels, meaning a quick comparison would fail:

el.style.width = "1em";
document.defaultView.getComputedStyle(el, null).width; // 16px

In addition to that testing against unsupported style values will not always return a definitive result where as support can be easily determined. For example, setting an element’s color to an unrecognized value will always result in the return of the rgb representation of the color black:

el.style.color = "test";
document.defaultView.getComputedStyle(el, null).color; // rgb(0,0,0)

To quickly resolve this and avoid making some elaborate parsing method, we need to use a secondary test case. We create a new element as part of our base element’s innerHTML and add the styling we wish to test for as inline styles. When we retrieve the new element and examine its style, we find that unsupported style values will always return an empty string:

el.innerHTML = '<div style="color:test ; width:10px"></div>';
el.firstChild.style.color !== ""; // false
el.firstChild.style.width !== ""; // true

Using this technique means any styles supplied must be in standard hyphenated CSS format (background-color) as opposed to the previous method which must be handed camel-cased styles (backgroundColor). This means that we need to include a function to handle camel case conversions; a small hit on performance yes, but also some syntastic sugar for the method – give and take I suppose.

Throwing these new techniques together results in a method capable of determining support for not only styles but their supported assignable/recognizable values by supplying an optional second parameter.

isStyleSupported = (function(){
    var cache = {};
    var el = document.createElement('div');
 
    var toCamelCase = function(str){
        var parts = str.split('-'), camel = parts[0];
        for(var i=1, len=parts.length; i < len; i++){
            camel += parts[i].charAt(0).toUpperCase() + parts[i].substring(1);
        }
        return camel;
    };
 
    return function(style, value){
        var key = style + value || "";
        if(key in cache){
            return cache[key];
        }else{
            var supported = false;
            var camel = toCamelCase(style);
            if(el.runtimeStyle){
                try{
                    el.style[camel] = value || "";
                    supported = typeof el.runtimeStyle[camel] !== 'undefined';
                }catch(e){};
            }else{
                var view = document.defaultView;
                if(view && view.getComputedStyle){
                    var cs = view.getComputedStyle(el, null)[camel];
                    supported = typeof cs !== 'undefined';
                    if(value){
                        el.innerHTML = '<div style="'+style+':'+value+'"></div>';
                        supported = supported && el.firstChild.style[camel] !== "";
                    }
                }
            }
            return cache[key] = supported;
        }
    }
})();

So how reliable are the methods? Well in all my testing in all the browsers I could get my hands on – I encountered just one false positive, that being fixed positioning in IE6, something I am still struggling to explain. To test the reliability yourself, I have put together a simple test page which includes various styles and their corresponding results when tested against isStyleSupported. In addition to that, I have included two text inputs so you can try and test any styles you wish.

Hopefully we’ll see some of the developers of the mainstream libraries take notice and employ these or similar techniques in future versions of their respective frameworks and finally rid themselves of the unreliable browser detection so many of them still utilize today in cases such as this.

Here, I present to you my version appropriately named FX. The motive here was to create a simple script for your basic animations and of course to be library independent, with emphasis on lightweight. Where I have strayed away from the other solutions found in various frameworks is that I’ve stripped out most of the extra features, electing instead for the core functionality. The syntax is similar to that which you would find in YUI, I find it simple yet covers all the bases pretty well. I drew inspiration for the programming behind it from Mootools due to its simplicity as a whole. To use it is pretty simple; just tell it what to do, give it a duration, optional callback, and then let it fly.

Features

• Perform tween on almost all CSS properties
• Supports both scroll and color animations
• Allows for both to and from values for each attribute
• Supports transitional easing
• Optionally assign a callback and context to execute the function in upon animation completion
• Supports IE6+, FF, Opera, Safari, and Chrome
• No browser detection

Example

The syntax is pretty straigth forward, as I mentioned before it looks similar to what you would find in YUI. The following example demonstrates just some of the attributes supported for animation. For a more impressive sampling of FX, see this example.

var fx = new FX('element', {
    'top': {to: 500},
    'left': {to: 300},
    'width': {from: 100, to: 300},
    'height': {from: 100, to: 200},
    'scrollLeft': {from: 0, to: 50},
    'background-color': {from: '#FF0000', to: '#0000FF'}
}, 1.5, callback, context);
 
fx.start();

At the moment, only pixels are supported as the default units for all animations, and there is only one type of transitional easing available. At some later point in time I will be updating to add support for both of these features, so check back soon!

Download

• Compressed (4kb)
• Fully Documented (8kb)