Content can be inserted into your page using innerHTML or outerHTML…

var container = document.getElementById("container");
container.innerHTML = "<p>Here's some new <strong>DOM</strong> content.</p>";

(Note that jQuery also uses innerHTML for DOM content manipulation).

It’s fast and easy — but it’s not without problems:

1. Invalid HTML strings can be inserted which make errors difficult to spot and debug.
2. You may encounter browser issues if you attempt complex activities such as using or modifying nodes in the resulting DOM content.
3. Although it’s well supported, innerHTML is a proprietary technology and not part of the W3C DOM. It offends the standards gods.

So let’s look at the DOM-based alternative:

var newpara = document.createElement("p");
var newstrong = document.createElement("strong");
newstrong.appendChild(document.createTextNode("DOM"));
newpara.appendChild(document.createTextNode("Here's some new "));
newpara.appendChild(newstrong);
newpara.appendChild(document.createTextNode(" content."));
var container = document.getElementById("container");
container.appendChild(newpara);

Nasty. It’s three times longer, slower to execute and still prone to human error.

Several years ago I devised by own solution, BetterInnerHTML, which loaded an HTML string as XML, recursed the structure and inserted appropriate nodes into the DOM. It worked, but I was never totally happy with performance or issues such as HTML entities.

Fortunately, Joe Stelmach has devised an alternative. It’s a small standalone utility named Laconic which uses a logical JavaScript notation to map directly to HTML, e.g.

$.el.p(
	"Here's some new ",
	$.el.strong("DOM"),
	" content."
).appendTo(document.getElementById("container"));

Attributes are supported using object literal notation:

// produce <div class="example"><div>Content</div></div>
$.el.div(
	{ "class": "example"},
	$.el.div("Content")
);

I like it. While innerHTML remains the best option for quick and dirty DOM content generation, Laconic will be useful in those odd situations when it fails to work as expected.

For more information and downloads, refer to:

• Laconic on GitHub
• Laconic example page

In February 2012, we reported the minutes of W3C meeting where Mozilla, Opera and Microsoft discussed implementing -webkit prefixes in non-webkit browsers. The reason: some developers use only webkit prefixes — their sites look good in some browsers, but broken in others even when they offer the same level of CSS3 support. The issue is especially prevalent on mobile browsers and many developers fail to look beyond their high-end Apple or Android devices.

Opera has now announced support for 14 CSS3 webkit properties in their Mobile Emulator. The implementation will eventually reach all editions of their desktop and mobile browsers. If you’re thinking “Opera has a tiny market share”, think again: it’s the world’s most-used mobile browser.

Perhaps I’m being overly dramatic, but Charlton Heston’s famous line comes to mind: “They finally, really did it. You manics. You blew it up!”

Opera -webkit Aliasing

Opera analyzed stylesheets from 10,000 popular websites to determine which CSS values/properties would receive -webkit aliases:

If the browser encounters a property such as -webkit-border-radius, it will apply that effect. If you’ve defined -webkit-border-radius, -o-border-radius and border-radius, normal CSS cascading rules apply and the last defined rule or most appropriate selector will be applied, e.g.

#myelement
{
	-o-border-radius: 3px;
	border-radius: 6px;
	-webkit-border-radius: 9px;
}

All properties are considered to have equal priority so Opera applies a border radius of 9px.

With regard to differences in behavior, Opera state:

As far as we can tell, the behavior the properties that we have aliased is identical in WebKit and Opera, or at least close enough that the differences will not matter in practice. If it turns out that there are differences big enough to cause breakage, we will consider our options, one of which is to align the behavior of our -webkit- prefixed variant to what WebKit actually does.

Opera make a reasonable case to justify their decision. While they understand the complaints, their primary goal is to create a browser which works well for users — who outnumber developers by many thousands to one.

The Backlash

Most developers understand the problem but disagree with the solution. It’s crude and has the potential to break the web. Taking the decision to it’s logical extreme, all vendors would support every prefix but any implementation differences would render the CSS property useless.

The solution rewards bad development practices. While Opera advises you use all vendor prefixes, they will exacerbate the problem:

• Less conscientious developers will see this as justification for only targeting webkit browsers.
• If your site uses differing -webkit and -o values, it will now be affected by CSS cascade rules. Is it easier to analyze and retest your code or simply remove the Opera properties?
• It will become easier to accidentally omit the -o prefix since sites will work as expected.

Several problems have already been reported. For example, Modernizr evaluates prefixes in turn until it finds one the browser supports. Therefore:

Modernizr.prefixed("transition");

now returns WebkitTransition in Opera. Transitions are new to Opera and the browser doesn’t support every webkit CSS and JavaScript property. If you want to adjust or disable effects in Opera, you can’t rely on Modernizr-like detection code. You may even need to implement nasty browser sniffing.

However, my biggest issue is this: where are all these problem sites? Has user experience suffered from the lack of rounded corner, gradient, shadow, transition and transform effects? Are those sites genuinely broken or has Opera taken a (marketing) opportunity to make their browser look better?

Since Opera has analyzed 10,000 websites they can contact the owners directly. At the very least, they could publish a “hall of shame” which provides examples and highlights the technical issues. Many developers would happily contact companies on Opera’s behalf. Some would be prepared to fix sites for free since it could lead to future contracts.

There are no easy solutions to the vendor prefix crisis. I understand Opera’s reasons but, regardless of how this is implemented, it’s inevitable that something will end up broken.

Some good news: Microsoft has announced they will not support webkit prefixes in Internet Explorer (although there’s nothing to prevent them reversing that decision). Mozilla is yet to reveal their intentions — they will be watching Opera’s situation closely.

Supporting the mouse wheel can add further interactivity to your HTML5 web pages. Rather than scrolling the page, you could perform a different action such as zooming in or out.

View the mouse wheel demonstration page…

Most browsers support the “mousewheel” event for any element. You can register a handling function which is passed an event object. This exposes a wheelDelta property; a positive value for scrolling up or a negative value for scolling down. The larger or smaller the value, the bigger the movement.

Unfortunately, there’s one browser which doesn’t support the the “mousewheel” event. You’re wrong: it’s Firefox. Mozilla has implemented a “DOMMouseScroll” event. This passes an event object with a detail property but, unlike wheelDelta, it returns a positive value for scrolling down. So, until Mozilla adopt the event, we have a bizarre situation where it’s actually a little easier to code for IE6! That’s not something you hear said every day.

You should also note that Apple disable the scroll wheel in Safari, but support is available in the webkit engine so your code won’t cause any problems.

Adding a mousewheel Event Handler

Let’s add an image to our web page which will zoom in and out in response to the mouse wheel:

<img id="myimage" src="myimage.jpg" alt="my image" />

We can now attach the mousewheel event handler:

var myimage = document.getElementById("myimage");
if (myimage.addEventListener) {
	// IE9, Chrome, Safari, Opera
	myimage.addEventListener("mousewheel", MouseWheelHandler, false);
	// Firefox
	myimage.addEventListener("DOMMouseScroll", MouseWheelHandler, false);
}
// IE 6/7/8
else myimage.attachEvent("onmousewheel", MouseWheelHandler);

The Cross-Browser mousewheel Event Handling Function

Our MouseWheelHandler can now determine the wheel movement delta. In this case, we’re going to reverse Firefox’s detail value and return either 1 for up or -1 for down:

function MouseWheelHandler(e) {
	// cross-browser wheel delta
	var e = window.event || e; // old IE support
	var delta = Math.max(-1, Math.min(1, (e.wheelDelta || -e.detail)));

We can now size the image accordingly. The code below sets a width between 50px and 800px, but you could determine the image’s natural dimensions and use that.

	myimage.style.width = Math.max(50, Math.min(800, myimage.width + (30 * delta))) + "px";
	return false;
}

Finally, we return false to cancel the standard event which would normally scroll the page.

View the mouse wheel demonstration page…

The code works in every browser, including IE6, 7 and 8, but Safari users won’t see anything happening.

The -9999px image replacement technique has been popular for the best part of a decade. To replace a text element with an image, you use the following code:

<h1>This Text is Replaced</h1>
<style>
h1
{
	background: url("myimage") 0 0 no-repeat;
	text-indent: -9999px;
}
</style>

The element’s background is displayed and it’s text is moved off-screen so it doesn’t get in the way. Simple and effective. It was often adopted to show graphical titles — that’s rarely necessary now we have webfonts, but you’ll still find it used all over the web.

Until now.

A new technique has been discovered by Scott Kellum and promoted at Zeldman.com:

#replace
{
	text-indent: 100%;
	white-space: nowrap;
	overflow: hidden;
}

The code indents the text beyond the width of its container but it won’t wrap and the overflow is hidden.

While it’s a little longer and more difficult to remember, performance can be improved because the browser’s no longer drawing a 9,999px box behind the scenes. It will also prevent the weird left-extended outlines you’ll see around links using hidden text.

I haven’t been able to discover any downsides — only than I wish I’d discovered it first. Have you adopted the technique? Have you experienced any issues?

Flash has offered a full-screen mode for many years but, until now, browser vendors have resisted the feature. The main reason: security. If you can force an app to run full-screen, the user loses their browser, taskbar and standard operating system controls. They may not be able to close the window or, worse, nefarious developers could emulate the OS and trick users into handing over passwords, credit card details, etc.

At the time of writing, the HTML5 full-screen API has been implemented in Firefox, Chrome and Safari. Mozilla provide good cross-browser details but it’s worth noting that the specifications and implementation details are likely to change.

Unlike pressing F11 to make your browser go full-screen, the API sets a single element full-screen. It’s intended for images, videos and games using the canvas element. Once an element goes full-screen, a message appears temporarily to inform the user that they can press ESC at any time to return to windowed mode.

The main properties, methods and styles are:

element.requestFullScreen()
Makes an individual element full-screen, e.g. document.getElementById(“myvideo”).requestFullScreen().

document.cancelFullScreen()
Exits full-screen mode and returns to the document view.

document.fullScreen
Returns true if the browser is in full-screen mode.

:full-screen
A CSS pseudo-class which applies to an element when it’s in full-screen mode.

Vexing Vendor Prefixes

Don’t bother trying to use these API names. You’ll require vendor prefixes for BOTH the CSS and JavaScript properties:

There’s no support in Internet Explorer or Opera yet, but I would suggest you use the ‘ms’ and ‘o’ prefixes for future proofing.

I’ve developed a function in the demonstration page which handles the prefix shenanigans for you:

var pfx = ["webkit", "moz", "ms", "o", ""];
function RunPrefixMethod(obj, method) {
	var p = 0, m, t;
	while (p < pfx.length && !obj[m]) {
		m = method;
		if (pfx[p] == "") {
			m = m.substr(0,1).toLowerCase() + m.substr(1);
		}
		m = pfx[p] + m;
		t = typeof obj[m];
		if (t != "undefined") {
			pfx = [pfx[p]];
			return (t == "function" ? obj[m]() : obj[m]);
		}
		p++;
	}
}

We can then make any element viewable full screen by attaching a handler function which determines whether it’s in full-screen mode already and acts accordingly:

var e = document.getElementById("fullscreen");
e.onclick = function() {
	if (RunPrefixMethod(document, "FullScreen") || RunPrefixMethod(document, "IsFullScreen")) {
		RunPrefixMethod(document, "CancelFullScreen");
	}
	else {
		RunPrefixMethod(e, "RequestFullScreen");
	}
}

The CSS

Once the browser enters full-screen mode you’ll almost certainly want to modify the styles for the element and it’s children. For example, if your element normally has a width of 500px, you’ll want to change that to 100% so it uses the space available, e.g.

#myelement
{
	width: 500px;
}
#myelement:full-screen
{
	width: 100%;
}
#myelement:full-screen img
{
	width: 100%;
}

However, you cannot use a list of vendor prefixed selectors:

/* THIS DOES NOT WORK */
#myelement:-webkit-full-screen,
#myelement:-moz-full-screen,
#myelement:-ms-full-screen,
#myelement:-o-full-screen,
#myelement:full-screen
{
	width: 100%;
}

For some bizarre reason, you must repeat the styles in their own blocks or they won’t be applied:

/* this works */
#myelement:-webkit-full-screen	{ width: 100% }
#myelement:-moz-full-screen		{ width: 100% }
#myelement:-ms-full-screen		{ width: 100% }
#myelement:-o-full-screen		{ width: 100% }
#myelement:full-screen			{ width: 100% }

Weird.

View the demonstration page in Firefox, Chrome or Safari…

The technique works well. The only issue I’ve discovered concerns Safari on a two-monitor desktop — it insists on using the first monitor for full-screen mode even if the browser is running on the second screen?

While it’s possibly a little early to use full-screen mode, games developers and video producers should keep an eye on progress.

There are some great jQuery plugins. The better ones are adopted by thousands of web developers throughout the world. Unfortunately, the worse ones fail and disappear into obscurity. Here are some tips to ensure your plugins reach their full potential…

1. Don’t Break the Chain

Unless your plugin returns a value, the last line of your plugin function must be:

return this;

this ensures method calls can be chained, e.g.

$("div#myid").yourPlugin().anotherPlugin().yetAnotherPlugin();

2. Make it Easy to Use

In most cases, your plugin should simply work without the developer having to wade though documentation, set options or edit your plugin code.

If it’s a visual widget, the developer shouldn’t need to edit any JavaScript. You can simply provide HTML with a class/ID which will automatically launch your code, e.g.

<section class="myjqWidget">
<p>My content</p>
</section>

Your plugin can initialize itself, e.g.

$(function() {
		$("section.myjqWidget").myjqWidget();
});

3. Use Suitable Naming and Version Control Numbers

There are a lot of jQuery plugins. If you’re considering the name “tab” for your tab-handling plugin, there’s a strong possibility it’s been used already. That may not always matter but avoid using names which are ambiguous or likely to clash.

Version numbering is also useful. It’s becomes especially important when developers report problems.

4. Use a Closure

Never depend on ‘$’ referencing jQuery. If the developer has another library installed, it may have grabbed it before jQuery was loaded. The simplest way to solve the issue is to pass jQuery as the ‘$’ argument for an anonymous self-starting function, e.g.

(function($) {
	// code here can use $ to reference jQuery
})(jQuery);

5. Set Default Parameters

Most plugins set parameters using JavaScript object literal notation, e.g.

$("#select").MyPlugin({opt1: 1, opt2: 2, opt3: "three"});

This has several advantages: parameters are easy to read, can be ordered in any way and omitted completely. However, you should set defaults within your plugin code and override them accordingly, e.g.

$.fn.PlugIn = function(opts) {
	// default configuration
	var config = $.extend({}, {
		opt1: 1,
		opt2: 2,
		opt3: 3,
		opt4: 4,
		opt5: 5
	}, opts);

Your plugin can then reference parameters using code such as config.opt1.

6. Support HTML Parameters

Ideally, HTML widgets should be able to set parameters without the developer needing to change JavaScript code. You could consider HTML5 data attributes, e.g.

<section class="myjqWidget" data-opt1="1" data-opt2="two">
<p>My content</p>
</section>

These can be accessed via jQuery’s data method: .data("opt1").

7. Document Your Code

Add concise comments to the top of your plugin which describe:

• the plugin name and version
• what the plugin does
• example uses
• the parameters
• contact and support links

If it’s particularly complex, consider a separate readme file.

8. Test Your Plugin Thoroughly

Test it. Then test it again. In all browsers.

There may be issues you’re not prepared to fix, e.g. IE6 compatibility problems. That’s fine, but ensure it’s mentioned within your documentation.

9. Use a Good Template

Here’s the template code I use when creating a new plugin:

/*!
 * jQuery plugin
 * What does it do
 */
(function($) {
	$.fn.PlugInName = function(opts) {
		// default configuration
		var config = $.extend({}, {
			opt1: null
		}, opts);
		// main function
		function DoSomething(e) {
		}
		// initialize every element
		this.each(function() {
			DoSomething($(this));
		});
		return this;
	};
	// start
	$(function() {
		$("#select").PlugInName();
	});
})(jQuery);

It provides a good starting point:

• The plugin is wrapped in an enclosure.
• It sets default options which are overridden by plugin parameters.
• Each selected element is passed to the DoSomething function as a jQuery object.
• return this; is included.
• Auto-start code is provided at the end.

10. Get The Word Out

If you want developers to use your plugin, upload it to repositories such as GitHub, Google Code and jQuery Plugin directories. Create demonstration pages, publicize it in articles and tweet about it incessantly.

Then be prepared to support the plugin and update it when necessary. You will receive dumb questions and bizarre feature requests, but that’s all part of being a successful plugin author.

Do you have any top-tips for effective jQuery plugin development?

There’s an inevitable delay whenever your web application interacts with the server. That could be for an Ajax request, uploading a file, or using newer HTML5 APIs such as web sockets or server-sent events.

Ideally, you should give the user some feedback to indicate their action is being processed. You’ll often see small animated GIFs with rotating patterns. There are several sites which will create them for you, such as preloaders.net and ajaxload.info.

Images are the best cross-browser option but they have a number of issues:

• GIFs do not support alpha-transparency. You need to be careful when placing the image on a colored background.
• Bitmap images won’t scale nicely. If you change the dimensions, you need to create a new image.
• If you’re not careful, animated graphics can have a large file size.
• Images incur an additional HTTP request. While the image will be cached, the initial download may take longer than the background process it represents! You can code around this issue by pre-loading the image or using embedded data URLs but it’s more effort.

Fortunately, CSS3 allows us to create loading icons without images. They’re easy to create, scale, re-color, use on any background and don’t incur image downloads. You require:

1. A single HTML element, e.g. <div id="ajaxloader"></div>.
2. A few CSS backgrounds, border and shading effects to create a graphical icon.
3. CSS3 transformations and animations to rotate or move the element.

View the demonstration page…

Browser Compatibility

CSS3 transformations and animations are experimental properties which require vendor prefixes — and you know what trouble they cause. The example code implements the final property as well as prefixes for -webkit (Chrome and Safari), -moz (Firefox), -ms (IE), and -o (Opera), but there’s no guarantee they’ll work consistently if at all.

At the time of writing, recent versions of Chrome, Safari and Firefox offer CSS3 animations. IE9/8/7/6 and Opera show a static image, although IE10 and Opera 12 may support the properties.

Just to complicate matters further, Firefox allows you to animate pseudo elements separately. You can therefore add a couple of elements using :before and :after and rotate or move them in different directions to create more complex animations. While I’d initially hoped to do that, it doesn’t work in the webkit browsers. Chrome and Safari only allow real elements to be animated. It appears to be a bug or oversight, but it’s not been fixed in the current or beta releases.

Creating the Icon

Our HTML div can be placed anywhere in the document although it might be best to append it as the last child of the body. It will then appear above other elements and can be positioned in relation to the page.

The icon CSS simply sets wide white rounded border. The right border color is then set to transparent and a little shading is applied:

#ajaxloader
{
	position: absolute;
	width: 30px;
	height: 30px;
	border: 8px solid #fff;
	border-right-color: transparent;
	border-radius: 50%;
	box-shadow: 0 0 25px 2px #eee;
}

The result:

It’s easy to tweak the properties for different effects, e.g. adding border-right: 0 none; produces:

Animating the Icon

To make the icon spin and pulsate, we apply rotation transformations and opacity changes within a CSS3 animation. The animation name, duration, easing type and repeat are applied to the element:

#ajaxloader
{
	animation: spin 1s linear infinite;
}

followed by the animation keyframes:

@keyframes spin
{
	from { transform: rotate(0deg);   opacity: 0.2; }
	50%  { transform: rotate(180deg); opacity: 1.0; }
	to   { transform: rotate(360deg); opacity: 0.2; }
}

None of the browsers support animation without vendor prefixes so you’ll see -webkit, -moz, -ms and -o alternatives within the source code when you view the demonstration page.

The icon can now be displayed using a little JavaScript whenever an Ajax request is initiated. It’s a great effect which can be customized easily and works on 55% of current browsers.

Unfortunately, 45% of web users won’t see the animation. That number will fall when IE10 is released and users switch to recent versions of other browsers, but it remains a large percentage. You could fall back to an image but, if you’re doing that, you might as well use the image for all browsers.

I therefore suggest you look at your own statistics. If your visitors are are predominately using Chrome, Safari and Firefox you could adopt the technique today. If not, stick with images for now and wait a little longer for more consistent browser support.

You knew this was coming. Yes, I still love CSS3 and use it every day — but that doesn’t mean I’m happy with everything. To counterbalance Viki Hoo’s 5 Things I Love About CSS3, here are five things which frustrate me…

1. Property Overload

How often did you consult manuals or reference materials when writing CSS2.1 code? After learning the basics, I suspect you only required a cursory glance now and again.

Those days are gone. Perhaps it’s just me but the sheer volume of new tags is overwhelming. Even when I know a property exists it’s impossible to recall the values. Has anyone learned the all the background gradient and border image options?

While CSS3 definitely saves time, you’ll need to consult online manuals or tools every few minutes.

2. Vendor Prefixes

Vendor prefixes are absolutely necessary. I use them and accept it’s the price to pay for cutting-edge techniques. That doesn’t mean I have to like them. Other developers don’t either — otherwise we wouldn’t be heading for a CSS3 catastrophe.

At best, prefixes result in clunky repetition. At worst, they use completely different syntaxes. There are JavaScript and server-side pre-processors which help ease the burden but none are perfect. After all, if a property doesn’t work in a particular browser is it a problem with your CSS, the browser, or the automatic code-creation tool you’re using?

3. Developer Tools

It’s difficult for any IDE vendor to keep up with the rapid pace of CSS3 development. Does anyone know of an editor which supports all the new properties and syntaxes with all the vendor-prefixed differences? I don’t.

It’s not all bad; there are a number of great online CSS3 tools. However, you still won’t find many decent validators.

4. Browser Support and W3C Politics

Browser vendors have different priorities and release schedules. While it’s easy to pick on IE (IE9 doesn’t support text shadow), even webkit isn’t consistently ahead of the game (Chrome doesn’t support separate animation of pseudo elements). One browser will always be more capable than another, but hype and marketing often get in the way of development. How often have you assumed a browser supports property X, written some code and found it doesn’t work?

The major vendors belong to the W3C and work together to agree standards. In reality, they’re competitors:

• Apple has been accused of implementing iPhone/iPad-specific features which are promoted as an “HTML5 standard” but never submitted to the W3C.
• The proposal to support webkit prefixes in non-webit browsers could break CSS3 as we know it.
• The lethargic rate of the standards approval process highlights the disagreements and political battles.

It’s frustrating. Developers are caught in the crossfire but there isn’t a simple solution. And, before anyone suggests it again, dropping all but one of the rendering engines is not an option and will stagnate innovation.

5. Silly Shim Shenanigans

CSS3 rounded corners have save hours of time during every project. There’s no need for convoluted layouts or multiple background images. Unfortunately, they won’t work in IE8 or previous incarnations of the browser. You therefore have three options:

1. Forget CSS3 and use traditional development techniques.
2. Accept that no two browsers render the same. IE8 is three years old and was released before the industry jumped on the HTML5 bandwagon. Pages viewed in IE8 will look different (and uglier) to IE9, Firefox, Chrome, Safari and Opera.
3. Try and make IE8 look good using JavaScript shims which normally implement old IE-specific filters.

I recommend option two. You may need to educate your clients but their costs will be reduced and, ultimately, it may persuade users to upgrade their browser.

Unfortunately, I keep find sites which add a plethora of shims in a futile attempt to achieve pixel perfection. While pages may look better, it results in bulky code and IE8 often becomes frustratingly slow. I can’t believe their clients were pleased with the result.

In Summary

CSS3 is great. In terms of practicality, it’s progressed faster and is more useful than HTML5 or the assorted JavaScript APIs.

Browser compatibility is an issue but Viki is confident that “the day they are unified will eventually come”. I’m not convinced. We will reach a point when CSS3 is fully implemented but we’ll be moaning about CSS4 by then!

Vendor prefixes enable web developers to experiment with new standards before they reach the Candidate Recommendation stage. I previously wrote how these prefixes are also a mechanism browser vendors use for handling timing conflicts between implementations and specifications. In building demos of new features for our IE Test Drive site and in various presentations, many of us on the IE team deal extensively with vendor prefixes.

This article describes a pattern our team has used to make things significantly easier when developing with vendor prefixes.  We’d like to share it with you and hear your thoughts on this approach or any others you consider a best practice.

Error-Prone Code

When using script to access CSS properties with vendor prefixes, it’s easy to end up with code that looks like this:

var elm = document.getElementById("myElement");
elm.style.msTransitionProperty = "all";
elm.style.msTransitionDuration = "3s";
elm.style.msTransitionDelay = "0s";
elm.style.webkitTransitionProperty = "all";
elm.style.webkitTransitionDuration = "3s";
elm.style.webkitTransitionDelay = "0s";
elm.style.MozTransitionProperty = "all";
elm.style.MozTransitionDuration = "3s";
elm.style.MozTransitionDelay = "0s";
elm.style.OTransitionProperty = "all";
elm.style.OTransitionDuration = "3s";
elm.style.OTransitionDelay = "0s";

While functional, it’s bloated, ugly, and error-prone.

Consolidating Vendor-Prefixed Properties to a Single Name

A better pattern is to define a method that loops through a list of property names and returns the first supported property or null if the browser doesn’t support any of them.

function FirstSupportedPropertyName(prefixedPropertyNames) {
    var tempDiv = document.createElement("div");
    for (var i = 0; i < prefixedPropertyNames.length; ++i) {
        if (typeof tempDiv.style[prefixedPropertyNames[i]] != 'undefined')
            return prefixedPropertyNames[i];
    }
    return null;
}

We then initialize a variable for each vendor-prefixed property we use, passing it an array of possible properties in the order we prefer to use them.

var transformName = FirstSupportedPropertyName(["transform", "msTransform", "MozTransform", "WebkitTransform", "OTransform"]);
var backfaceVisibilityName = FirstSupportedPropertyName(["backfaceVisibility", "msBackfaceVisibility", "MozBackfaceVisibility", "WebkitBackfaceVisibility", "OBackfaceVisibility"]);
var transitionName = FirstSupportedPropertyName(["transition", "msTransition", "MozTransition", "WebkitTransition", "OTransition"]);
var animationName = FirstSupportedPropertyName(["animation", "msAnimation", "MozAnimation", "WebkitAnimation", "OAnimation"]);
var gridName = FirstSupportedPropertyName(["gridRow", "msGridRow", "MozGridRow", "WebkitGridRow", "OGridRow"]);
var regionsName = FirstSupportedPropertyName(["flowFrom", "msFlowFrom", "MozFlowFrom", "WebkitFlowFrom", "OFlowFrom"]);
var hyphensName = FirstSupportedPropertyName(["hyphens", "msHyphens", "MozHyphens", "WebkitHyphens", "OHyphens"]);
var columnName = FirstSupportedPropertyName(["columnCount", "msColumnCount", "MozColumnCount", "WebkitColumnCount", "OColumnCount"]);

Then code throughout your site that uses these properties becomes something like this:

var elm = document.getElementById("myElement");
if (transitionName) {
    elm.style[transitionName + "Property"] = "all";
    elm.style[transitionName + "Duration"] = "3s";
    elm.style[transitionName + "Delay"] = "0s";
}
else {
    // fallback for browsers without CSS3 transitions
}

Note the simple feature detection enabled by returning null in FirstSupportedPropertyName.

That pattern also works when CSS properties have vendor prefixes. You can use a slightly different pattern for cases where a CSS value (for example, linear-gradient) has vendor prefixes:

function FirstSupportedFunctionName(property, prefixedFunctionNames, argString) {
    var tempDiv = document.createElement("div");
    for (var i = 0; i < prefixedFunctionNames.length; ++i) {
        tempDiv.style[property] = prefixedFunctionNames[i] + argString;
        if (tempDiv.style[property] != "")
            return prefixedFunctionNames[i];
    }
    return null;
}
var linearGradientName = FirstSupportedFunctionName("backgroundImage", ["-ms-linear-gradient", "-moz-linear-gradient", "-webkit-linear-gradient", "-o-linear-gradient"], "(top, black, white)");
var radialGradientName = FirstSupportedFunctionName("backgroundImage", ["-ms-radial-gradient", "-moz-radial-gradient", "-webkit-radial-gradient", "-o-radial-gradient"], "(50% 50%, circle cover, black, white)");

Testing Sites that Use Vendor-Prefixed Properties

A common question is what property names to use if some browsers don’t yet support the property or if no browser supports the standards-based property without a prefix. There are a couple approaches, each with merit:

1. Always include all expected names, even if they don’t yet work in shipping browsers. The benefit of this path is that as browsers add support with their vendor prefix or add support for the non-prefixed property, your site will “just work” without changes. The risk is that the site will automatically pick up behavior you’ve never tested. A vendor prefix indicates the behavior isn’t finalized and all prefixed properties and the non-prefixed property may not behave the same, so as browsers add support your site might “just not work.”
2. Only include property names you can test. The benefit is that your site will behave the same as when you first wrote it even as browsers add support for new properties. The risk is that you have unnecessarily degraded functionality. For sample or demo sites, people can interpret this as a browser not having a feature at all.

You need to determine the right path for your site. In most of our demos we want to show off new web platform functionality in any browser that supports it. And since small errors in these demos don’t create big problems for users, we usually choose option #1. On the other hand, if you have a production site where a change in behavior will cause a problem for your business, you may opt for the more risk-averse path.

Regardless of which path you choose, the one constant is testing. When using vendor-prefixed properties you’re leveraging early, often unstable functionality that can change even after a browser first introduces support for a property, so it’s critical to test with each browser update to make sure your site functions as expected.

Hey there, all you JavaScript and jQuery wannabes!

As part of the launch of our latest book “jQuery: Novice to Ninja, 2nd Edition. — New Kicks and Tricks” we’re laying down the challenge for all of you to test your jQuery knowledge. Below, you’ll see a screenshot of the first of nine sets of questions from our jQuery Ninja Test.

Take the test, and see if you can attain jQuery Ninja status!

Developers have a love-hate relationship with CSS vendor prefixes. They allow us to use bleeding-edge technologies at the expense of long-winded declarations:

background-image: -webkit-linear-gradient(#fff, #000);
background-image: -moz-linear-gradient(#fff, #000);
background-image: -ms-linear-gradient(#fff, #000);
background-image: -o-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);

It works well in theory but consider what happens in the wild:

1. Experimental properties are often implemented in the webkit engine first and there’s no guarantee they’ll be replicated in other browsers.
2. It’s often difficult to determine whether a vendor-prefixed property is part of the CSS specification. Some vendors don’t submit properties for standardization.
3. Even if the standard property changes, the incorrect vendor-prefixed version continues to be supported. Your old code still works; you won’t revisit it to correct the implementation.

You’ll often find sites using the -webkit prefixes alone — even if other browsers support the property or it has widespread availability without a prefix (such as border-radius). Chrome and Safari therefore look better than competing browsers — and the other vendors aren’t happy.

The issue was raised and discussed in the W3C meeting on February 7, 2012:

Web standards activists are teaching people to use webkit. You will see presentations from all the web standards advocates advocating people to use webkit prefixes.

Our job is to solve interoperability.

At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla.

If we don’t support webkit prefixes, we are locking ourselves out of parts of the mobile web.

Let that sink in for a moment.

Non-webkit browsers will support the -webkit prefix. That is the solution being considered by the W3C.

The idea is likely to fail miserably. Two or more implementations of the same webkit property won’t be compatible so developers won’t be able to use it anywhere. No one wins — including Apple and Google.

But I’m more concerned about the irreparable damage it’ll cause if the solution is successful. Once developers discover webkit prefixes working in Firefox, IE and Opera, they’ll expect them to work on all properties. Webkit-only adoption will rise exponentially and the vendors will be forced to implement the prefixes throughout. At that point, webkit properties will become the de facto standard regardless of any W3C specification. Game over: the open web is closed.

The implications also go further than CSS: many of the new JavaScript APIs have vendor prefixes.

Who’s to Blame?

We can point the sticky finger of failure at:

The W3C Working Group
It takes too long for web standards to reach maturity. That may be unavoidable but browser vendors are bypassing the process.

Browser Vendors
In their rush to push new technologies, it’s too easy for vendors to add a prefix and forget about it. Web developers require more information: is the property being considered by the W3C and when will the prefix be dropped?

In an ideal world, experimental prefixes would disappear once the browser implements the standard property. Vendors won’t do that because it’d break sites, but they could do more to highlight the problem, e.g. provide obsolescence detection tools or output error messages to the developer console.

Apple and Google
Both are guilty of promoting webkit prefixes as though they’re a standard part of day-to-day HTML5 web development. Apple has been accused of actively working against the W3C.

Mozilla, Microsoft and Opera
Other vendors are often months behind the webkit browsers — if not years. Adding webkit prefixes is a ludicrous solution: it’s time to up their game.

Technology Websites and Evangelists
We all love cool demonstrations but evangelists often neglect to mention that properties are experimental and may never have full browser support (and, yes, that includes SitePoint). Ideally, code should work in at least two browsers; at least it would indicate that multiple vendor prefixes are required.

Web Developers
We’re too lazy. We’re writing browser-specific code and, while we may have good intentions about correcting it later, we rarely do.

Do you recall the last time developers targeted a specific browser? It was IE6. We’re still living with the legacy of that decision a decade later. Do you really want history to repeat itself?

It’s Time to Act

I’m opposed to non-webkit browsers supporting webkit prefixes. At best, it makes prefixes unusable. At worst, it breaks the whole standardization process. You may agree or disagree but make your opinion known to colleagues, in blogs and on social networks. The W3C and browser vendors will listen to your feedback; you just need to provide some.

Then test your site in multiple browsers. A little graceful degradation is fine but neglecting one or more modern browsers with equivalent support is not. Fix the code, otherwise your site is contributing to the problem.

The js1k competition is back. While it may have started as a joke, it continues to attract amazing entries from JavaScript ninjas eager to demonstrate their coding prowess.

The competition — code named Love ’12 — runs until midnight on March 14, 2012. There are various cash prizes for the winners and the rules remain simple:

• You may submit as many entries as you like but only one submission per person will be entered in the competition.
• You must provide a JavaScript code of no more than 1,024 bytes (that’s not necessarily characters).
• An HTML5 page is provided which contains a single canvas tag, some set-up variables and a script tag for your code. You don’t need to use canvas or the variables although most entries do.
• Minification is permitted but it must not change your original variable names.
• Loading external resources, libraries, frames or other sites is forbidden. You’ll be found out so don’t bother trying!
• Your code must run in the latest versions of Firefox, Chrome, Opera and Safari. Preferably, it’ll run in IE9/10 too but that’s not essential since the browsers are only available on recent editions of Windows.
• Your code should behave itself, not cause crashes and behave equally well in all browsers.

The theme of “Love” is suggested but it’s not a requirement (there are far too many animated hearts already!) My favorites so far include:

• Chain Reaction
• 1K Minesweeper
• A Rose is a Rose
• Campsite Firefighter
• Funky Fabric

What are you waiting for? Happy coding and feel free to post a link to your submissions in the comments section below…

See also: What can YOU do with 1 Kilobyte of CSS?

Today’s HTML5 applications can provide awesome experiences thanks to the new CSS3 specifications. One of them is CSS3 Animations. It can help you building rich animations on HTML elements. This can provide interesting feedbacks to the users and enables fast & fluid UIs. As those new animations are most of the time hardware accelerated by the GPU, they definitely raise the quality bar of the new generation of HTML5 applications.

According to the “CSS Animation Module Level 3” specification on the W3C site, CSS3 Animations introduces defined animations, which specify the values that CSS properties will take over a given time interval. This specification is an extension to CSS Transitions.

As CSS3 Animation is an extension to CSS3 Transitions, you should first read the article of my colleague David Catuhe on Transitions here: Introduction to CSS3 Transitions.

We’ll see in this article an interesting demo highlighting the potential of CSS3 animations, how to build simple animations & how to handle fallback in JavaScript:

1. CSS3 Animations
2. Browsers Support
3. CSS3 Animations JavaScript fallback library
4. Conclusion

Let’s first start by quickly demonstrating what CSS3 Animations are. Here is a sample animation of a Star Wars AT-AT which uses CSS3 Animations to animate parts of the transport (and which will fall back to JavaScript if your browser doesn’t support CSS3 Animations):

You can test this sample also in a separate window here: http://david.blob.core.windows.net/html5/css3atat/index.htm

Note: this sample has been tested successfully with native animations under IE10 PP3/PP4, Chrome 15, Firefox 8 & iPad 2 and with JS fallback under IE9 desktop & mobile (Windows Phone). For an unknown reason, it behaves in weird way under Opera 11.50 but works fine with the 11.60. Moreover, our lovely blogging platform is most of the time forcing the IE9 rendering engine via a meta tag. To force it back to the IE10 standards mode, press the F12 key and change the value of “Document Mode” back to IE10. Otherwise, view the demo in a separate window.

This sample is based on the awesome work done by Anthony Calzadilla. You can check other incredible demos on his website here: http://www.anthonycalzadilla.com . I’m a huge fan of the I twitty the fool sample using SVG & CSS3 Animation for instance.

CSS3 Animations

Introduction

Let’s first review on what you can play to build the animations. CSS3 Animations works basically on the same values as CSS3 Transition.

Here they are:

• color: interpolated via red, green, blue and alpha components (treating each as a number, see below)
• length: interpolated as real numbers.
• percentage: interpolated as real numbers.
• integer: interpolated via discrete steps (whole numbers). The interpolation happens in real number space and is converted to an integer using floor().
• number: interpolated as real (floating point) numbers.
• transform list: see CSS Transforms specification: http://www.w3.org/TR/css3-2d-transforms/
• rectangle: interpolated via the x, y, width and height components (treating each as a number).
• visibility: interpolated via a discrete step. The interpolation happens in real number space between 0 and 1, where 1 is “visible” and all other values are “hidden”.
• shadow: interpolated via the color, x, y and blur components (treating them as color and numbers where appropriate). In the case where there are lists of shadows, the shorter list is padded at the end with shadows whose color is transparent and all lengths (x, y, blur) are 0.
• gradient: interpolated via the positions and colors of each stop. They must have the same type (radial or linear) and same number of stops in order to be animated.
• paint server (SVG): interpolation is only supported between: gradient to gradient and color to color. They then work as above.
• space-separated list of above: If the lists have the same number of items, each item in the list is interpolated using the rules above. Otherwise, no interpolation.
• a shorthand property: If all the parts of a shorthand can be animated, then interpolation is performed as if each property was individually specified.

And the following properties must be supported for animations:

• background-color (color)
• background-image (only gradients)
• background-position (percentage and length)
• border-bottom-color (color)
• border-bottom-width (length)
• border-color (color)
• border-left-color (color)
• border-left-width (length)
• border-right-color (color)
• border-right-width (length)
• border-spacing (length)
• border-top-color (color)
• border-top-width (length)
• border-width (length)
• bottom (length and percentage)
• color (color)
• crop (rectangle)
• font-size (length and percentage)
• font-weight (number)
• grid-* (various)
• height (length and percentage)
• left (length and percentage)
• letter-spacing (length)
• line-height (number, length and percentage)
• margin-bottom (length)
• margin-left (length)
• margin-right (length)
• margin-top (length)
• max-height (length and percentage)
• max-width (length and percentage)
• min-height (length and percentage)
• min-width (length and percentage)
• opacity (number)
• outline-color (color)
• outline-offset (integer)
• outline-width (length)
• padding-bottom (length)
• padding-left (length)
• padding-right (length)
• padding-top (length)
• right (length and percentage)
• text-indent (length and percentage)
• text-shadow (shadow)
• top (length and percentage)
• vertical-align (keywords, length and percentage)
• visibility (visibility)
• width (length and percentage)
• word-spacing (length and percentage)
• z-index (integer)
• zoom (number)

SVG

The properties of SVG objects are animatable when they are defined as animatable:true in the SVG specification: http://www.w3.org/TR/SVG/struct.html. But at the time where this article is written, I didn’t manage to combine CSS3 Animation directly on SVG elements in any of the latest browsers versions. Today’s samples on the web are then doing a little trick: they are embedding SVG resources into different DIV animated by CSS3 like the I twitty the fool sample.

Declarations

To declare an animation in a CSS file, here is the kind of generic code you’ll need to write:

@keyframes name_of_the_animation {
  from {
    property_to_animate: initial_value;
  }
  50% {
    property_to_animate: intermediate_value;
  }
  to {
    property_to_animate: final_value;
  }
}

Which could also be written like that:

@keyframes name_of_the_animation {
  0% {
    property_to_animate: initial_value;
  }
  50% {
    property_to_animate: intermediate_value;
  }
  100% {
    property_to_animate: final_value;
  }
}

This animation definition declares 3 steps 0, 50 & 100%. You should at least set a from (or 0%) and a to (or 100%) steps to build a correct animation (minimum 2 steps thus). Once done, you may add as many keyframes as you’d like between 0 and 100% to handle precisely the various steps of your animations.

Once the definition is declared, you can affect it to an element using the classical CSS3 selectors and you’ll need also to configure the animation options. Here the kind of generic blocks you’ll see:

#id_of_the_html_element {
    animation-name: name_of_the_animation;
    animation-duration: number_of_seconds s;
    animation-iteration-count: number | infinite;
}

To better understand, let’s review a real sample. First of all, as the CSS3 Animations specification is still in a draft stage, you’ll need to use the appropriate vendor prefix. Let’s use IE10 as a sample with the –ms prefix then. Let’s now see how the head of our AT-AT is moving.

Here’s the animation declaration:

@-ms-keyframes rotate-skull {
    0% {
        -ms-transform: rotate(0deg)
    }
    25% {
        -ms-transform: rotate(15deg)
    }
    50% {
        -ms-transform: rotate(-5deg)
    }
    55% {
        -ms-transform: rotate(0deg)
    }
    75% {
        -ms-transform: rotate(-10deg)
    }
    100% {
        -ms-transform: rotate(0deg)
    }
}

We’ve got 6 steps (0, 25, 50, 55, 75 & 100%) working on the CSS3 2D transform attributes by changing the value of the rotation.

The animation is then applied via this CSS rule:

#skull
{
    -ms-animation-name: rotate-skull;
    -ms-animation-duration: 7s;
    -ms-animation-iteration-count: infinite;
}

We’re targeting the <div> element having the “id=skull” and we’re applying the animation named “rotate-skull” on it. The animation will have to be completed in 7s and be played an infinite number of times.

Here is the living result if your browser supports CSS3 Animations:

We could have written this rule in a shorter manner using the animation shorthand property:

#skull {
    -ms-animation: rotate-skull 7s infinite;
}

The animations will be triggered as soon as a matching rule is applied. You can then play or stop animations simply via JavaScript or via CSS3 to play with the classes affected to a tag.

Non-linear animations

The “animation-timing-function” property can be used if you want non-linear animations. You can even mix the type of timing functions during each keyframe.

Basically, CSS3 animations will use cubic bezier curve to smooth the animation by computing different speed over its duration.

The following functions are supported:

• linear: Constant speed
• cubic-bezier: Speed will be computed according to a cubic bezier curve define by two control points : P0 and P1 (so you will have to define 4 values here : P0x, P0y and P1x, P1y.
• ease: Speed will be computed with cubic-bezier(0.25, 0.1, 0.25, 1)
• ease-in: Speed will be computed with cubic-bezier(0.42, 0, 1, 1)
• ease-inout: Speed will be computed with cubic-bezier(0.42, 0, 0.58, 1)
• ease-out: Speed will be computed with cubic-bezier(0, 0, 0.58, 1)

Here is a simulation tool written by David Catuhe that uses pure JavaScript to show the impact of each timing function:

Note: this tool uses in-line SVG supported by Firefox, Chrome, Opera 11.60 & IE9/10. It won’t work properly under Opera 11.50 & Safari on iPad thus.

This is an awesome tool using SVG. You can even play with your mouse on the custom function to edit the curve. If you’d like to know more about this tool, please again have a look to David’s article.

If your browser supports CSS3 animations, let’s now see a simple demo using easing functions to animate a canvas tag containing an animated sprite with CSS3.

Here is the CSS3 animations code that will be used in this demo:

@-ms-keyframes demo {
    from {
    -ms-animation-timing-function: ease;
    -ms-transform: translateX(0px);
    }
    50% {
    -ms-animation-timing-function: ease-in;
    -ms-transform: translateX(300px);
    }
    to {
    -ms-animation-timing-function: ease-inout;
    -ms-transform: translateX(900px);
    }
}
#testCanvas
{
    -ms-animation-delay: 0s;
    -ms-animation-duration: 6s;
    -ms-animation-iteration-count: infinite;
    -ms-animation-name: demo;
}

As well as all the vendor prefixes variations to make sure it works also in Google Chrome & Mozilla Firefox. And here’s the living output:

If your browser doesn’t support CSS3 Animation but support canvas, the sprite’s running animation should be displayed but the character won’t move through the width of the screen.

Note: if you’d like to know more about canvas and sprites animation, you can have a look to this article: HTML5 Gaming: animating sprites in Canvas with EaselJS

Delay

The “animation-delay” property simply allows an animation to begin execution some time after it is applied.

Events

3 events could be raised during an animation. They are named “AnimationStart”, “AnimationEnd” and “AnimationIteration”. Depending on your browser, the correct name will be for instance:

• Chrome: webkitAnimationEnd
• Firefox: mozAnimationEnd
• Internet Explorer: MSAnimationEnd

The event will give you the following details:

• animationName: name of the animation which raised the event
• elapsedTime: the amount of time the animation has been running, in seconds

Here is an usage sample for IE10:

elementToAnimate.addEventListener("MSAnimationEnd", function () {
    alert("the end !");
}, false);

More about CSS3 animations

CSS3 animations are really useful for 2 main reasons:

• Hardware acceleration: CSS3 Animations are most of the time directly handled by the GPU and could produce smoother results. This could then be a very interesting approach for mobile devices.
• Better separation between code and design: I know there is some debates on this point but with David, we think that a developer shouldn’t be aware of animations or anything related to design as much as possible. In the same way the designer/artist must not be aware of JavaScript. CSS3 offers then this possibility and could let the designers work with their classical tools to generate the appropriate animations on elements, between screens, etc.

To highlight this importance in performance, the following HTML5 game I wrote using a full frame <canvas>: HTML5 Platformer run at 60 fps in IE9/IE10 on my PC but at 10 fps max on a iPad 2. This is because its CPU is much more limited and the iPad is currently not hardware-accelerating <canvas>. Using CSS3 Transitions/Animations to animate several smaller <canvas> elements could provide a huge performance boost for this game. Think about it when you’re targeting mobile devices!

Browsers Support

Since the Platform Preview 3 of IE10 available in the Windows Developer Preview, we’re supporting CSS3 Animations. And as you can see on the following report produced by caniuse.com, the CSS3 animations are now supported on a wide range of browsers:

But as the specification is not finished yet (working draft), you must use vendor’s prefixes such as –ms-, –moz-, –webkit-, –o- to make a cross-browsers compatible application.

But the question could be: how to handle browsers that don’t support this new feature?

First option is to just do nothing. Thanks to the beauty of graceful degradation, you could just let the user only see a static image if you’ve worked correctly. This is for instance the case of these 2 original samples of Anthony: I Twitty the Fool! and Pure CSS3 AT-AT Walker . When watched in IE9, it looks like we only have a static image. When watched in IE10, the very same code shows nice animations. IE10 users will then have an enhanced version while IE9 will still be able to view and use properly the website. The more modern your browser is, the more visual bonus you will have.

The second option is to detect the feature via a JS library like Modernizr and try to offer the same animation via a JavaScript library that will mimic the animations. This is what we usually call a fallback mechanism. Unfortunately, I haven’t found today a working & complete JS library that could replace CSS3 animations when not supported by the browser.

I have then written a sample JS library more or less specifically designed for the AT-AT sample.

CSS3 Animations JavaScript fallback library

Animations are nothing more than a series of transitions separated by a certain duration defined via the keyframes. I’ve then reused the concepts built by David Catuhe in his transitions helper library. I let you reviewing his article to check the base of the concepts behind the code.

On my side, I’ve added some support to animate the CSS3 2D Transform rotation & translation values and a way to iterate through the keyframes.

Here is the main part of the library you need to review:

// Animation object
// It need the HTML targeted element, the name of the animation, its duration & iteration count and
// the keyframes contained in an array object
// View the animation simply as a sequence of transitions played a certain number of times
ANIMATIONSHELPER.animation = function (target, name, duration, iterationcount, keyframes) {
    // saving the properties values
    this.name = name;
    this.duration = duration;
    this.iterationcount = iterationcount;
    this.target = target;
    var elapsedtime = 0;
    var keyframeduration = 0;
    var elapsedtime = 0;
    // Transforming the percentage of each keyframe into duration value
    for (var i = 0; i < keyframes.length; i++) {
        keyframeduration = ((keyframes[i].percentage * duration) / 100) - elapsedtime;
        keyframes[i].duration = keyframeduration;
        elapsedtime += keyframeduration;
    }
    this.currentTransition = { isPlaying: false };
    this.keyframes = keyframes;
    this.keyframesCount = keyframes.length;
    this.currentKeyFrameIndex = 0;
    // The nextTransition() function return the next transition to run
    // based on the current keyframe to play
    this.nextTransition = function (keyframe, ease, customEaseP1X, customEaseP1Y, customEaseP2X, customEaseP2Y) {
        var properties = [];
        var finalValues = [];
        var transition;
        // Compared to the original TRANSITIONSHELPER of David Catuhe
        // We need a specific code to play with the CSS3 2D Transform properties values
        if (keyframe.propertyToAnimate === "transform") {
            for (var i = 0; i < keyframe.transformType.length; i++) {
                properties.push(keyframe.transformType[i].type);
                if (keyframe.transformType[i].type == "rotate") {
                    finalValues.push({ deg: keyframe.transformType[i].value1 });
                }
                else {
                    finalValues.push({ x: keyframe.transformType[i].value1, y: keyframe.transformType[i].value2 });
                }
            }
            // Create a new transition
            transition = {
                name: this.name + this.currentKeyFrameIndex,
                target: this.target,
                properties: properties,
                finalValues: finalValues,
                originalValues: ANIMATIONSHELPER.extractValues(target.style[ANIMATIONSHELPER.currentTransformProperty], this.name),
                duration: keyframe.duration,
                startDate: (new Date).getTime(),
                currentDate: (new Date).getTime(),
                ease: ease,
                customEaseP1X: customEaseP1X,
                customEaseP2X: customEaseP2X,
                customEaseP1Y: customEaseP1Y,
                customEaseP2Y: customEaseP2Y,
                isPlaying: true,
                type: "transform"
            };
            return transition;
        }
        // If it's a classic property to animate, we're using more or less the TRANSITIONSHELPER as-is
        else {
            return TRANSITIONSHELPER.transition(this.target, keyframe.propertyToAnimate, keyframe.value, keyframe.duration, TRANSITIONSHELPER.easingFunctions.linear);
        }
    };
    // each animation object has a tick function
    // that will be called every 17 ms (to target 60 fps)
    // This ticker is monitoring the current state of the transition and
    // create a new transition as soon as the old one is finished/dead
    this.tick = function () {
        if (this.iterationcount > 0) {
            if (!this.currentTransition.isPlaying) {
                this.currentTransition = this.nextTransition(this.keyframes[this.currentKeyFrameIndex], ANIMATIONSHELPER.easingFunctions.linear);
                // We're using our own global ticker only for the 2D transformations
                // Otherwise, we're using the one from the TRANSITIONSHELPER library
                if (this.currentTransition.type === "transform") {
                    ANIMATIONSHELPER.currentTransitions.push(this.currentTransition);
                }
                this.currentKeyFrameIndex++;
                // We've reached the last keyframe (100%). We're starting back from the beginning
                if (this.currentKeyFrameIndex >= this.keyframesCount) {
                    this.currentKeyFrameIndex = 0;
                    this.iterationcount--;
                }
            }
        }
    };
};

The first part of the code is iterating through each keyframe to compute the exact duration specified by each percentage. We’re then defining a nextTransition() function that will dynamically build the next transition to play based on the current index into the keyframes collection. At last, we’ve got a tick() function that will monitor the current state of the transition applied. Once the transition is finished or dead, it asks for the next transition, push it to the stack of transitions to be played and moves the indexes.

This tick() function is called thanks to this code:

ANIMATIONSHELPER.launchAnimation = function (animation) {
    // Launching the tick service if required
    if (ANIMATIONSHELPER.tickIntervalID == 0) {
        ANIMATIONSHELPER.tickIntervalID = setInterval(ANIMATIONSHELPER.tick, 17);
    }
    // Little closure to launch the tick method on the appropriate animation instance
    setInterval(function () { animation.tick(); }, 17);
};

At last, we have this kind of code that helps us building the keyframes:

// Object to build a new generic keyframe (not working on the CSS3 2D Transform properties thus)
ANIMATIONSHELPER.keyframe = function (percentage, propertyToAnimate, value) {
    this.percentage = percentage;
    this.propertyToAnimate = propertyToAnimate;
    this.value = value;
};
//Objects to build specific rotation keyframes
ANIMATIONSHELPER.rotationkeyframe = function (percentage, value) {
    this.percentage = percentage;
    this.propertyToAnimate = "transform";
    this.transformType = [];
    this.transformType.push(new ANIMATIONSHELPER.transformType("rotate", value));
};

To highlight its usage, let’s recreate the previous simple CSS3 Animation skull sample with this library :

// number of times you'd like the animations to be run
var iterationsNumber = 100;
var skullElement = document.getElementById("skull");
var keyframes = [];
keyframes.push(new ANIMATIONSHELPER.rotationkeyframe(25, 15));
keyframes.push(new ANIMATIONSHELPER.rotationkeyframe(50, -5));
keyframes.push(new ANIMATIONSHELPER.rotationkeyframe(55, 0));
keyframes.push(new ANIMATIONSHELPER.rotationkeyframe(75, -10));
keyframes.push(new ANIMATIONSHELPER.rotationkeyframe(100, 0));
var animation1 = new ANIMATIONSHELPER.animation(skullElement, "rotate-skull", 7000,
                            iterationsNumber, keyframes);
ANIMATIONSHELPER.launchAnimation(animation1, ANIMATIONSHELPER.easingFunctions.linear);

And here is the result that will now work in every browser supporting CSS3 2D Transform:

At last, the very first sample demonstrated at the beginning of this article uses Modernizr to check the support for CSS3 Animations. If it’s not the case, it loads the code that will mimic the keyframes defined in the file master.css, moz-master.css & ms-master.css :

// Checking if CSS3 animations is supported
if (!Modernizr.cssanimations) {
// if so, we can use our JS fallback library
    supportElement.innerHTML = "CSS3 Animations <strong>are not supported</strong>";
    LoadJSAnimationsFallback();
}
else {
    // if CSS3 animation is supported, we have nothing to do.
    // The *master.css stylesheets will be automatically applied & used.
    supportElement.innerHTML = "CSS3 Animations <strong>are supported</strong>";
}

The LoadJSAnimationsFallback() function is defined into jsfallback-master.js which simply contains all the keyframes declarations and the 19 animations needed to mimic the behavior created by Anthony in pure CSS3. In this approach, the designer then needs to rewrite all rules using the library. Another approach could be to parse one of the CSS file using an XHR call and to create dynamically the JavaScript calls to the library. This needs more work as you almost need to reimplement the CSS3 animations specifications in JavaScript!

You now have an idea on the way to build a fallback mechanism to support more browsers while starting to use the latest CSS3 specifications.

You can download the files for the main sample here: http://david.blob.core.windows.net/html5/css3atat/CSS3ATATNonMinified.zip

It contains the unminified versions of the animationsHelper.js, transitionsHelper.js, jsfallback-master.js JavaScript files as well as the various CSS3 declinaison files for the main vendors prefixes.

Conclusion

CSS3 Animations is a powerful technology to push HTML5 applications to a new level. It offers interesting scenarios. Designers could use it to create a new generation of UI screens with smooth & fluid animations without the need of developers. As it’s hardware-accelerated most of the time, developers should also pay attention to this specification. At last, both could collaborate. Designers could work on a series of predefined animations covering most scenarios. Developers could then create JavaScript libraries that will implement those animations. This library could offer in a transparent way 2 implementations: a dynamic generation of CSS3 on the fly or a fallback for older browsers.

Going further

• Article about CSS3 Transitions by David Catuhe: Introduction to CSS3 Transitions
• CSS3 Animations specifications: http://www.w3.org/TR/css3-animations/
• IE Test Drive on CSS3 animations: http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_animations.htm

Other useful posts:

• Events are relatively limited in the CSS3 Animation spec. Joe Lambert is proposing an interesting solution to trigger events on each keyframe: CSS Animation Keyframe Events (Javascript solution)
• CSS3 animation tutorial form SitePoint’s own Lead Designer Alex Walker, full of examples.

CSS pseudo-classes which change styles in response to user actions have been with us for many years. You’ve almost certainly used :hover, :active and :focus; I can (only just) remember the excitement of changing IE4′s link colors back in 1997.

CSS3 also introduced :target; a powerful pseudo-class which can reduce the need for scripting in interactive widgets. Consider a page URL such as http://mysite.com/page#mytarget; an element with the id “mytarget” can have matching :target styles applied.

:target Browser Support

All modern browsers support :target and you won’t experience problems with IE9 or most versions of Chrome, Firefox, Safari and Opera. Unfortunately, that still leaves us with the older versions of IE. I wouldn’t worry too much about IE6 and 7, but IE8 remains the world’s most used browser version. All is not lost, however, since shims such as selectivizr can add :target support without requiring complex workarounds.

A Simple Document :target

We’ve recently been discussing website contracts. Generic contract small print such as payment schedules, hosting conditions, cancellation terms, support policies, glossaries etc. could be contained in one or more web pages. The document could grow to a considerable length even if you try and keep it concise!

Let’s look at a snippet of the document’s HTML5 in contract.html:

<h1>Website Contract</h1>
<nav>
	<ul>
		<li><a href="#payment">Payment Schedule</a></li>
		<li><a href="#support">Support &amp; Maintenance</a></li>
		<li><a href="#hosting">Hosting Terms</a></li>
		<li><a href="#glossary">Glossary</a></li>
	</ul>
</nav>
<article id="payment">
<h2>Payment Schedule</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
</article>
<article id="support">
<h2>Support &amp; Maintenance</h2>
<p>Ut euismod tempor porttitor.</p>
</article>
<article id="hosting">
<h2>Hosting Terms</h2>
<p>Suspendisse ac nisl lorem, ut fermentum erat.</p>
</article>
<article id="glossary">
<h2>Glossary</h2>
<p>Aenean id nibh eget nisl blandit hendrerit lobortis ac tortor.</p>
</article>

We can use the :target attribute to highlight active sections, e.g.

article:target
{
	background-color: #ffc;
	border: 2px solid #fcc;
}

Anyone viewing the contract can click a navigation menu item to highlight the appropriate section. You can also issue direct links to clients who require specific information, e.g. contract.html#support.

The :target selector offers further versatility — it’s possible to create dynamic effects in HTML5 and CSS without using JavaScript. Further SitePoint articles are coming soon…