At a global level, CSS styles are added to the page using style sheets, which contain style declarations:

div.post {
    color: #CCCCC;
    display: inline-block;
    height: 20px;
}

This is an example style declaration, which should be familiar to you by now, since we saw something like this in Chapter 9, on Slick. At the start of the declaration is the selector, which defines which elements to apply the style to, followed by the style rules that are surrounded by the curly braces.

Each of these style rules defines the value of a particular visual property of the elements to which the rules apply. This declaration, for example, tells us that all div elements with the class post will have a font color of light gray (color: #CCCCCC), a visual display that makes it both an inline and a block element (display: inline-block), and a vertical dimension of 20 pixels (height: 20px).

A style rule—and therefore a visual property of an element—is usually one of four types:

All these rule types can be animated in one way or another, and we'll see how each of them is handled later on. An important thing to know right now, though, is that some rules—particularly color and numeric rules—are easier to animate than others.

We use style sheets to define these rules on a global level: style declarations in a style sheet are applied to all elements on a page that satisfy the selectors. But specific elements can also have their own set of styles that are defined using inline styles, which are style rules that are defined only for a specific element.

An inline style can be defined in HTML using the style attribute:

<div class="post" style="color: #000; display: inline;"></div>

Here we have a div element with a style attribute that defines its inline style. For this element, the color rule is given the #000 value, while the display rule is given the inline string value.

If this element appeared in the same document with a style sheet that includes the style declaration we have above, what would be the color and display visual property values of the div be? Would they be #CCCCCC and inline-block respectively, or #000 and inline? The answer, of course, is the latter. Inline styles take precedence over global styles, which means that if an element has an inline style rule declared, it will override any global styles for the same rule—except global rules declared with !important.

This precedence of inline styles over global styles is important because animation happens using inline rather than global styles. As we'll see later, it is the value of these inline styles that change rather than the global styles. This is because animation needs to be localized: if we change the value of an inline rule, it affects only the element where the inline rule is declared.

The global styles and inline styles that we define for our documents are called explicit styles, because we explicitly define them using style rules in style sheets or inline styles. We can find out the explicit styles in our documents in two ways.

For global style rules, we can inspect the document.styleSheets object, which is a node collection containing all the style sheet objects in a page. Inspecting this object can sometimes be complicated, though, because it uses multiple interfaces and objects.

Inline styles, on the other hand, are available directly by accessing the style object property of an element. For our div example, for instance, we can get the value of its color style by accessing div.style.color, which should give us the hex string '#000'. For CSS rule names that are hyphenated, such as background-color, the style object will use a camelcase variation of the name, like backgroundColor. If an element doesn't have an inline style defined, the value of the property will be an empty string, which means that accessing div.style.background in our example will yield "".

Explicit styles are only one piece of the puzzle, though. All style rules have, in fact, a default value. For example, the default value of the height rule is auto, which means that the item's height depends on its content. When creating style sheets or inline styles, we usually don't write down the values for all rules, but only for the rules whose default values are different from the ones we want. Styles whose values are not defined directly in the style sheet are said to be implicit styles. Included in the implicit styles category are styles that are inherited by an element from an ancestor or parent, such as color.

When it comes to styles, explicit styles trump implicit styles. Inline explicit styles are honored more than global explicit styles, and both inline and global explicit styles come before implicit styles. When you combine both the explicit and implicit styles that apply to an element, you get the complete set of styles for an element, and thus you get the element's computed styles.

Computed styles represent the final style that's applied to an element. For our div snippet, for example, the computed style for the color of the div will be #000, which is equal to the definition in the inline style, while the computed style for the height of the div will be 20px, which is equal to the definition in the global style sheet. And since there was no definition for it, the computed background-color style of the div will be transparent—the default implicit value for the style.

When dealing with computed styles, it's important to note that values such as auto don't exist because computed styles have concrete values. An auto value usually represents a value that automatically changes depending on the state of an element, like height based on the content of the element. When computed styles come into play, these auto values are turned into actual pixel values—so an element with a height set to auto in a declaration will have a height value equal to X pixels in computed styles.

This concreteness of computed styles is important because we need to deal with real values in animation. If we want to animate the height of a div by adding 20 pixels to it, for example, we need to be able to get the initial pixel value of the element's height so that we can increment it per frame. We can't do this using ambiguous values like auto—we need the actual, concrete numeric value.

In Chapter 8, when we talked about the Element type, we learned about the basic style methods such as getStyle and setStyle. We said that these methods are used to return and set the specific styles of the elements, and in part that's true. But since we now know more about CSS styles in general, we need to expand our discussion a bit.

The getStyle and setStyle methods can be considered "unified" methods: both can be used as interfaces to other related functions. The setStyle method, for instance, is mainly a wrapper for assigning properties to an element's style object. This means that doing something like el.setStyle('height', 'auto') is the same as doing el.style.height = 'auto'. Well, almost the same: aside from this simple style object assignment, setStyle can also handle things like setting opacity, which is really done using set('opacity'). Thus, we go back to the original premise: setStyle is a single interface to several different operations.

Like setStyle, getStyle is largely concerned with the style object. When we try to access an element's style value using getStyle, the method first checks the style object of the element to see if the specific rule is present. If it is, the value of this rule is simply parsed into a usable form and returned. However, if this rule isn't present in the style object, getStyle will call another method: getComputedStyle.

The getComputedStyle method has the same API as getStyle, but it checks the computed style of an element directly rather than checking the style object first. When we retrieve an element's style rule value using getComputedStyle, we actually access the final style value that's applied to the element. This means that all rules—both explicit and implicit—are available using getComputedStyle, which makes it very valuable.

One typical question about getStyle and getComputedStyle goes like this: "If getComputedStyle can give us the final value for any element style rule whatsoever, then why doesn't getStyle simply use getComputedStyle for everything?" This is a valid question. The truth is that for most cases, getStyle does use getComputedStyle for everything, since most elements won't have inline styles, which means they'll have blank style object properties. But on the other hand, MooTools does check the style object as much as it can for two reasons: because it's faster and because the value of the rule in the style object is actually the same as the value of the element's computed style, since inline styles have the highest precedence order.

The existence of a main loop lets browsers provide special functions called timers. A timer is a function that enables us to execute a function at a particular time. There are two timer functions in JavaScript: setTimeout and setInterval.

The setTimeout function takes two arguments: func, which is the function to run, and delay, which is a number representing the amount of time to wait before executing the function.

setTimeout(function(){
    console.log('Hello World!'),
}, 1000);

Here's an example of setTimeout that executes a function after a second. You'll notice that the delay number is in milliseconds, where one thousand milliseconds is equal to a second. When this snippet is run in the browser, the JavaScript interpreter will wait one second before invoking the function.

The other timer function, setInterval, also takes two arguments: func, which is the function to run, and interval, which is a number representing the amount of time to wait before executing the function. This function works similarly to setTimeout, but instead of simply delaying the execution of the function, it invokes the function at regular intervals.

setInterval(function(){
    console.log('Hello World!'),
}, 1000);

In this snippet we use the same arguments as we did for the setTimeout function. And as with setTimeout, the JavaScript interpreter will again wait one second before invoking the function. Unlike setTimeout, though, which invokes the function only once, setInterval will continue invoking the function regularly for an indefinite period of time. So after the first invocation, the interpreter will wait another second before invoking the function again, and then repeat this wait-invoke process indefinitely.

One important thing to know about these functions is that they're scheduling functions, not blocking ones. What this means is that when the interpreter sees an invocation of setTimeout or setInterval, it does not stop further execution in order to wait for these functions to finish. Instead, it takes the function arguments and the delay or interval value and stores them in a stack in order to access them later before continuing the execution. For example:

console.log('A'),
setTimeout(function(){
    console.log('B'),
}, 1000);
console.log('C'),

In this example we have a setTimeout call surrounded by two console.log invocations. When we run this on the browser, we get the following console output:

A
C
B

You'll notice that the order of the log is different from the order of console.log invocations in the snippet. This is because the interpreter doesn't wait for the function argument to be executed, but instead stores that function first. So what happened here is that the first log output, A, was logged first, then the interpreter saw the call to setTimeout. It then stored the function argument to setTimeout in a stack before proceeding to the next line to output C. When the delay period specified for setTimeout passed, the interpreter finally called the function argument, so the B value is logged.

Both setTimeout and setInterval return a number value, called a timer identifier. This number is used if we need to disable the timer, which is especially useful for setInterval. Disabling a timer is called "clearing," and can be done using two functions: clearTimeout and clearInterval.

The clearTimeout function takes a single argument, id, and disables a setTimeout timer associated with that id:

var id = setTimeout(function(){
    console.log('Hello World!'),
}, 1000);

clearTimeout(id);

In this snippet, we first stored the identifier of the timer in a variable called id. We then immediately called on clearTimeout, passing the identifier we stored. This means that the function will never be called, because we disable the execution of the timer function immediately.

As you might guess, clearInterval is used to disable a setInterval timer. Like clearTimeout, it also takes a single id argument:

var count = 0;

var id = setInterval(function(){
    console.log('Hello'),
    count++;
    if (count === 3) clearInterval(id);
}, 1000);

Here we have an example of a self-disabling interval function. We first set up a counter that increments for each invocation of the function argument. We then set the function argument to run every one second using the setInterval function. When the function argument has been invoked three times, we call clearInterval to disable the timer, stopping our function from further executing.

Since the setTimeout and setInterval functions are mostly concerned with executing function arguments, MooTools implements two Function methods that employ these two timer functions, delay and periodical, which we've already seen in Chapter 2. Like setTimeout and setInterval, these two function methods return a timer identifier that can be used with the clearTimeout and clearInterval functions.

JavaScript's single-threaded nature has a very interesting effect on timers. Remember that the global scope and function scopes have separate execution contexts, which the interpreter "enters" and "exits" during the course of a program. Because JavaScript is single-threaded, only a single execution context can be active at any point in the program's lifetime.

This one-context-at-a-time design affects timers immensely because timers are run in a separate execution context. For instance, take a look at the following example:

var fn1 = function(){
    setTimeout(function fn2(){
        console.log('fn2'),
    }, 0);
    console.log('fn1'),
};

fn1();

In this snippet we created a new function called fn1. Inside this function, we created a new delayed function called fn2 using setTimeout. What's different about this delayed function is that we set the delay amount to 0—which is like saying we don't want any delay in execution. So, we would likely assume that since there is no delay, fn2 will be executed immediately and our output will be 'fn2' and then 'fn1'. But when we run this, we see the following output:

fn1
fn2

Even though our fn2 function had a delay of 0, it wasn't executed immediately. Instead, the interpreter finished executing fn1 first before invoking fn2.

This is an important point to consider when working with timers. Because JavaScript is single-threaded, only a single execution context can be active at a time. In our example, fn2 can't be executed immediately even if the delay is 0 because at the point the timer went off, the interpreter was still busy interpreting fn1.

But timers aren't only competing with regular functions for execution, they are also competing with other timers. If a function delayed using a timer is executing, other timers that are set off during that time won't be able to execute as well, which means they'll be queued for later execution.

It is imperative that you remember this because it shows us a "flaw" in the timer system: most of the time, we can't trust timers to execute at exactly the time we specified. If there are no functions currently being executed, our timers will probably execute with a delay that's equal to what we specified. But if our application is busy with other things, we can't expect the timer to be really on time.

Unlike our native animation example, which uses variables and functions, the MooTools Fx system uses animation objects to perform the same set of tasks. An animation object is an instance of an Fx subclass like Fx.Tween or Fx.Morph that encapsulates the basic elements of the process, like timers and calculation functions, and controls the whole progression of the animation sequence.

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50
});

tween.start('left', 30);

Here we reimplemented our previous native animation example using an animation object that is an Fx.Tween instance. Unlike our native example, we didn't need to write a whole bunch of variables and functions, but instead simply instantiated a new animation object. Our tween object in this case contains all the necessary elements for performing the animation, and we triggered this by simply calling the start method.

Notice that the style property we're animating, left, and the value we want this item to take, 30, are passed as arguments to the start method rather than passed as options to the constructor. This is because all animation objects are generic by default: they don't describe the actual properties being animated, only the duration and speed of the animation itself. This makes animation objects reusable in a way that a single animation object can be used to animate different properties by changing the arguments to the start method.

tween.start('height', 30);
tween.start('width', 30);

However, this doesn't mean that it'll work as we'd expect. After our first call to start, the animation object will be in a working state, which means that it'll be busy performing the necessary actions to animate the height of the element.

If we call start again while the animation is in this state, the animation object will behave according to the value of its link option. If the link option has the value 'ignore', it will simply ignore the second call.

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50,
    link: 'ignore'
});


tween.start('height', 30);
tween.start('width', 30);

In this snippet we passed a link option with the value 'ignore' to our constructor. This tells the animation object to ignore any subsequent calls to start while the animation object is still busy with the previous call. Note that all Fx classes use 'ignore' as the default value for the link options, which means we don't need to include it explicitly:

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50
});


tween.start('height', 30);
tween.start('width', 30);

This example is the same as the previous one even if we didn't include the link option, because all animation objects have 'ignore' as their default link value if the option isn't specified.

Another possible value for the link option is 'cancel'. This tells the animation object that if the start method is called while it is in a working state, the new call should cancel the previous one and replace it:

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50,
    link: 'cancel'
});


tween.start('height', 30);
tween.start('width', 30);

In this snippet the second call to start will cancel the previous call, and then replace it. This means that the animation sequence that's changing the height property of the element will be stopped and the animation object will proceed with animating the width property.

Finally, animation objects can have the link option of 'chain', which stores subsequent calls to start for later processing.

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50,
    link: 'chain'
});


tween.start('height', 30);
tween.start('width', 30);

Here our animation object will store the second call to start in a queue. After the first animation sequence has finished, the animation object will then call the next one in the chain, making it possible to chain several animation sequences in order. We'll see how to combine animation sequences when we look at Fx.Morph later in the chapter.

Tween and Morph are the two main Fx classes are used for animation in MooTools. These classes have very similar APIs, with the exception of having different signatures for their start methods. Because they're inherently similar, we'll take a look first at their differences before discussing the common methods of their APIs.

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50
});

var tween = new Fx.Tween('square', {
    duration: 1000,

fps: 50
});

tween.start('height', 30);

tween.start('height', 20, 30);

var morph = new Fx.Morph('square', {
    duration: 1000,
    fps: 50
});

morph.start({
    'height': 30,
    'width': 30

});

morph.start({
    'height': [20, 30],
    'width': 30
});

As you'll notice above, both Fx.Tween and Fx.Morph have almost the same APIs, except for signature differences in the start method. These two classes actually inherit from the same base class as we'll see later, which gives them the same set of methods. Some of the shared methods, like start, are overridden by these two classes, but most of them are shared.

One of these shared methods, cancel, is the opposite of the start method and triggers the animation to stop:

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,
    fps: 50,
});

tween.start('left', 30);

tween.cancel();

Here we called the cancel method immediately after calling start, which forces the animation sequence to halt entirely.

Of course, there are times when you don't want to completely cancel an animation sequence, but simply stop it for a bit and continue later. You can do this using the pause and resume methods:

var square = $('square'),

var tween = new Fx.Tween(square, {
    duration: 1000,

fps: 50,
});

tween.start('left', 30);

tween.pause();

setTimeout(function(){
    tween.resume();
}, 500);

In this snippet we called the pause method of our object immediately after calling start, halting the animation sequence. We then set a timer function to continue the animation using the resume method. The result is that our animation will stop for a bit, before continuing after half a second.

Animation objects, like other MooTools classes, function as event dispatchers, which means we can add event handlers that will get invoked at particular stages of the animation sequence. This is because Fx implements the Events mixin internally, which gives our animation objects the necessary event APIs.

There are three main events dispatched by the Fx classes:

You can add event handlers for these events using the addEvent methods we've already seen in previous chapters. Another way would be to pass the event handlers using the options argument:

new Fx.Tween('square', {
    onStart: startFn,
    onCancel: cancelFn,
    onComplete: completeFn
});

All event handlers for these events are invoked with a single argument, element, which is the element that's being animated.

The Fx class is at the root of the MooTools animation system. This class defines the most basic components required to produce animations, and all animation-related classes inherit from Fx.

The Fx class uses all of the three built-in mutators: Options to allow passing option objects during instantiation, Events to enable animation objects to dispatch events and have event listeners, and Chain to enable the chaining of calls to the start method.

Fx.Durations = {'short': 250, 'normal': 500, 'long': 1000};

As we've seen, the Fx base class is mostly concerned with setting up a framework for the basic elements of animation. Fx itself is very important in the MooTools animation system, but it remains incomplete because it does not implement the higher-level parts.

In order to make Fx usable, it has to be subclassed, and new methods that handle the actual property computation and change need to be implemented. Fx is actually very flexible in that you can subclass it to handle any kind of animation. Luckily, MooTools does the grunt work for us by including an Fx subclass that handles CSS style animation—the most common animation done on the DOM—called Fx.CSS.

The Fx.CSS class implements all the necessary methods that are used for CSS style animations. These include basic methods like render and serve, which are concerned with the actual computation and setting of the properties using setStyle, and more complex methods like search, which is used to parse the document's style sheets to find default values for CSS class declarations.

The most interesting part of Fx.CSS, though, is the set of parsers used for computing the changes for CSS style values. There are three default parsers for Fx.CSS: String, Number and Color. These parsers, which are stored in Fx.CSS.Parsers, are used to parse values that will be employed in the animation sequence, and turn them into JavaScript objects that can be used in computational operations.

Like Fx, though, Fx.CSS is still unusable on its own. The API for Fx.CSS is a bit unpolished, so subclasses are needed to add a more refined abstraction for the class.

MooTools provides two of these abstractions: Fx.Tween and Fx.Morph. These two classes are subclassed from the Fx.CSS class, and implement the abstractions for tweening and morphing elements. We've already seen them at work, and I think we all can agree that they give us a very elegant API for working with CSS animations.