• Smoother Experience CSS transitions offer a smoother experience when compared to JavaScript animations. Since everything is being handled natively by the browser engine, we can get much smoother transitions.
• Mobile Performance This subcategory to the first note. While CSS transitions will most always provide a smoother experience in regular browsers, mobile devices will benefit from this the most. Since mobile devices lack the power that our desktops have, taking advantage of the browser engine for transitions is a must.

Gracefully Degrading

In most cases front end developers will err on the side of progressive enhancement. That is, to provide users who support newer technologies an experience with these technologies and user’s who do not support it will be left behind, in a usable state just without the bells and whistles. I consider this following method to be graceful degradation instead. The reason behind this is that we will not be removing the transition effects all together from the page, but rather the method that we are using to apply the transition will be different, degrading to JavaScript animations when CSS transitions are not available (More on this later).

Detecting our features

Moving forward with our graceful degradation, we must determine how to apply the transition effect for the user. This should almost never be done via browser agent detection but rather through feature detection. Instead of only serving CSS transitions to certain versions of a browser we should instead detect whether or not the user supports our feature, in this case, CSS transitions. This can be done through JavaScript early on before trying to transition. One option is to use the open source JavaScript library Modernizr. Modernizr will detect the HTML5 and CSS3 features that the browser has and you have the option to populate your HTML tag with classes which describe support. Along with these CSS classes, a Modernizr object is created which you can check with JavaScript to see features that are supported. Modernizr even supports the ability for you to customize the features it detects. If you plan on using a lot of feature detection, then I highly recommend using Modernizr.

However, in some cases you may not need all of the features that Modernizr provides and it would be wasteful to add the bloat it provides or we simply may not be able to add Modernizr to our page. In this case we can detect features ourselves. For our transitions example we will need to detect whether or not a CSS3 property is available in the user’s browser. Since as of this writing the transition property is prefixed by the vendor we will need to run through and check each vendor prefix version of the transition property to see if the users’ browser supports it or not.

// Check for CSS3 Transition Support
var doc = document;

var css_transitions = function() {
    var el = doc.createElement('div');
    var vendors = ['', 'Khtml', 'Ms', 'Moz',' Webkit','O'];

    for (var i = 0, len = vendors.length; i < len; i++) {
        var prop = vendors[i] + 'Transition';
        if (prop in el.style) return true;
    }

    return false;
}();

First, we create a test element in memory to test against. Then we create an array of vendor prefixes ['', 'Khtml', 'Ms', 'Moz', 'Webkit', 'O']. Note that our first entry is a blank string. This is so that when browsers have fully implemented the transition spec and vendor prefixes are no longer used, we detect the feature correctly. Now we loop through the array. For each iteration we create a property to test which is a combination of the vendor prefix and our base property, in this case Transition. So for example. we will test MozTransition. We test to see if the property exists as part of the test elements style property. If this comes back true, then our browser supports CSS transitions. In the case of our example we execute our function immediately and store the result in a variable called css_transitions.

Putting our css_transitions variable to use

Now that we’ve determined whether or not the user’s browser supports CSS transitions we need to go put it to work. In this case, let’s transition the opacity of an element:

<style type="text/css">
    .transition-me {
        -o-transition(opacity 0.25s linear 0s);
        -moz-transition(opacity 0.25s linear 0s);
        -webkit-transition(opacity 0.25s linear 0s);
        -ms-transition(opacity 0.25s linear 0s);
        transition(opacity 0.25s linear 0s);
    }
</style>

In this example we will use jQuery which provides us with a rather handy syntax for changing CSS properties on an element or calling an animation on an element. The syntax for each actually matches exactly when used which allows us to use a pretty simple idiom to transition with.

// Fade out .transition-me elements
var method = (css_transitions) ? 'css' : 'method';
$('.transition-me')[method]({
    opacity: 0
});

If you visit the jQuery documentation both the css and animate support a map syntax which allows us to send an object to the method call with a property we want to transition as the key and the value to transition to as the value. With this in mind, we can simply call the appropriate method (css or transition) on the element we want to transition.

A note on Progressive Enhancement

While this particular post discusses how to apply graceful degradation to CSS transitions there is still room for some progressive enhancement. What I mean by this is there are certain times where a transition or animation is key to the user’s experience. Transitions help guide the user through changes on the page. There are times however where transitions are just applied to add a certain level of eye candy. It is this class of transition that I would simply not provide in browsers which do not support it since they are not key to the user’s experience with the page.

Case Study

So why the image map? Take a look at the following image:

So our image above is triangular, and is intended to be clickable. The expectation is that only the triangular area should be clickable. So in order to accomplish this, I’ve decided to move forward with using an image map.

Things get a bit more complicated, though. The image above is actually repeated many times on a page. It acts as a flag to being a favorite of sorts. Furthermore, we are not simply sending the user to a page link, we are looking to use JavaScript events on the image map (and unobtrusively at that). This unobtrusive JavaScript must send an ajax request to the server depending on which instance of the image is actually being clicked. So we have our work cut out for us.

Setting up the image map

Getting the image map set up is pretty simple. Let’s start with defining the map:

<map name="my-map">
    <area id="fav-area" shape=poly, coords="0,0, 46,0, 46,46" href="#fav"> 
</map>

We’ve defined a map named my-map with some coordinates. Note our shape is set to poly and the coordinates provided. In order to determine these coordinates I simply opened up Photoshop and grabbed the x and y coordinates of the 3 corners of the triangle. Along with that, since we have no intent on passing the user to an actual link we’ve provided a dummy hash on the href.

Setting up the image

So now the the map is defined we’ll create an instance of the image and have it use the map we made:

<img src="/images/map-case-study.gif" usemap="#my-map">

Adding an event handler

Adding an event handler is pretty straight forward as you might expect. I’ll be using jQuery for the demonstration.

$(function() {
	$('map[name=my-map] #fave-area').click(function (e) {
		e.preventDefault();
		alert('Clicked!');
	});
});

So we can still target and add an event as you normally would to the area.

Multiple instances of the same image and image map

Now that we have our image map set up, let’s move forward with the more complicated setup. Take the HTML structure below:

<div id="node-1" class="my-node">
	<img id="study-1" src="/images/map-case-study.gif" usemap="#my-map">
</div>

<div id="node-2" class="my-node">
	<img id="study-2" src="/images/map-case-study.gif" usemap="#my-map">
</div>

<div id="node-3" class="my-node">
	<img id="study-3" src="/images/map-case-study.gif" usemap="#my-map">
</div>

<map name="my-map">
	<area id="fav-area" shape=poly, coords="0,0, 46,0, 46,46" href="#fav">
</map>

We have multiple nodes which aim to make use of the same case-study image and they all use the same image map to define the clickable area. Now the problem is, how do we determine which image was actually clicked?

Well first, we can make use of a DOM method called elementFromPoint. This method allows you to pass in x and y coordinates and retrieve the element that is found at the given coordinates. I never knew that this method existed until today and it’s a pretty interesting find.

Putting elementFromPoint to use

$(function() {
	$('map[name=my-map] #fave-area').click(function (e) {
		e.preventDefault();
		var trigger = document.elementFromPoint(e.clientX, e.clientY);
		alert(trigger.id);
	});
});

So we take the coordinates of the actual click event and pass it to the elementFromPoint function to grab the actual element the user was trying to click. One problem still exists though: This works fine in Firefox and Safari but Chrome (and IE as some have reported) will still return the map area when using elementFromPoint. In order to counter this, I’ve found that disabling the image map before running elementFromPoint will then yield our expected element. Of course, once we’re done finding the element we must re-enable the image map.

So how do we do this? Take a look at the final JavaScript:

$(function() {
	$('map[name=my-map] #fave-area').click(function (e) {
		e.preventDefault();
		
		// Cache all instances of the image
		var $all_instances = $('.my-node img');
		
		// Store the usemap in order to re-enable later
		var usemap = $all_instances.attr('usemap');
		
		// Reset the use of an image map on all instances of it
		$all_instances.attr('usemap', '');
		
		// Grap the actual trigger we were looking for
		var trigger = document.elementFromPoint(e.clientX, e.clientY);
		
		// Re-enable the image map on all the instances we disabled it on
		$all_instances.attr('usemap', usemap);
		
		// Do something useful with the information
		alert(trigger.id);
	});
});

The sample has moved to using the background-image property instead of the background property alone. This change has been made to resolve issues that occur when defining a background with the CSS based gradient but leaving out the other properties common to a background such as position or repeat. When these attributes are left out, browsers define default values which can yield unexpected results with the CSS gradients.

So, the following:

background: -webkit-gradient(
    linear,
    left bottom,
    left top,
    color-stop(0.33, rgb(99,168,125)),
    color-stop(0.67, rgb(129,202,163)),
    color-stop(0.84, rgb(155,243,196))
);

background: -moz-linear-gradient(
    center bottom,
    rgb(99,168,125) 33%,
    rgb(129,202,163) 67%,
    rgb(155,243,196) 84%
);

Becomes,

background-image: -webkit-gradient(
    linear,
    left bottom,
    left top,
    color-stop(0.33, rgb(99,168,125)),
    color-stop(0.67, rgb(129,202,163)),
    color-stop(0.84, rgb(155,243,196))
);

background-image: -moz-linear-gradient(
    center bottom,
    rgb(99,168,125) 33%,
    rgb(129,202,163) 67%,
    rgb(155,243,196) 84%
);

The live sample on the page also makes use of background-image as well, so you can view that as another reference to this update as well.

Thanks to Avi Mahbubani for pointing out the issue and helping come to a resolution.

Check out the changes live, visit the CSS3 Gradient Generator.

Release Notes

Color Format Selection

Color format selection: Choose how your colors are formatted, either RGB or HEX.

The gradient generator will store your preference for the next time you visit!

<dt>Copy the code!</dt>
<dd>Copies the output code to your clipboard for you so you can quickly grab your generated code.</dd>

<dt>UI Updates</dt>
<dd>Stripped down page to the core components of the gradient generator, moving it to the top of the fold.</dd>

CSS gradients are quite powerful and very useful, but when taking a first look at the markup for writing a code based gradient it can appear daunting. This is why I’ve decided to create the CSS3 Webkit Gradient Generator. Please note that the generator is intended to be viewed in a webkit browser. Live sampling of the gradient will not be available without a webkit browser.

The gradient generator has 2 goals. The first is to provide a showcase for the power of CSS gradients. The second, is to provide a graphical user interface in which a user can visually create gradient code to use in their CSS where they see fit. In order to do this, I tried to create a UI that appears familiar, such as that of a graphic editing tool like Adobe Photoshop. Providing color swatches to make up the gradient and a slider for each to determine the color’s position in the gradient.

Color Swatch Control

Once a color swatch is selected the user can use the color picker found on the right to adjust the swatch’s color. The color picker is provided by the ColorPicker jQuery plugin from eyecon.ro.

Gradient Direction Control

Along with this control, I have added the ability to set the direction of the gradient, allowing the user to take advantage of the keywords that are available (left, right, bottom, top) or use custom point locations.

Live Sampling

Note: Live sampling of the gradient colors requires a webkit browser.

Coming Soon

Let me know what you think of the generator so far as well as any features you may like to see.

Links

• Check out the code on GitHub
• Learn more about CSS3 Gradients in Webkit
• Visit the CSS3 Webkit Gradient Generator

While researching on the topic over the last few weeks, I discovered what I believe is a misconception of an iPhone web application, and my goal is to hopefully, clear things up.

Let’s start by defining some of the possible ways of targeting an iPhone user, which actually diverges into two separate categories of its own. The first and probably the most popular way of targeting an iPhone user is through an iPhone app, sold through the iTunes App store. Coding and compiling Objective C/Cocoa based native iPhone applications.

Yet there are still other ways of creating a custom user experience for a user on the iPhone.

Mobile Web Sites and Web Applications

With Smart Phones becoming so widespread companies are working harder towards providing users with access to their websites with mobile phone designed websites.

WAP (Wireless Application Protocol) sites have been around for several years; the WAP was established in 1998 and was created for less powerful, smaller phones that had limited web browsers. Today’s smart phones, however, are becoming more and more powerful and now provide users with a fully fledged web browser such as the iPhone’s mobile Safari.

So with this in mind, websites have two options. Leaving things alone and letting the phone’s browser do the work, which may work well in some cases; or create a smart phone targeted version of their website. One of the biggest issues though with leaving a website as is for mobile device users is the bandwidth that a user has. Sure, the page may render correctly and work just fine, but that doesn't mean it may not take a while to load all the resources used on the page. Many of those same resources just aren't needed on the mobile device.

Through the power of HTML 5, CSS 3, Javascript and CSS Webkit extensions a developer has incredible tools at their disposal to work with in order to make a mobile friendly page.

Webkit

One of the things I am most impressed with so far is the power that CSS3 and webkit extensions provide. More specifically, CSS based gradients, shadows, and animations. These are really amazing pieces of technology allowing to cut down on bandwidth issues created from using images for certain elements just because of a gradient or other effect, or eliminating the need of Flash or special javascript libraries for animations.

Let's take a closer look at the benefits of using CSS gradients to cut down on the number of images that are required to download. Perhaps you have a consistent gradient used on several buttons on a site. If you were to use images, you would have to re-cut each variation of button, which leads to longer page loads which is a major concern when working on a mobile device. Now with a CSS gradient, we can define it as a single class and apply it to any buttons that use the gradient, making much better use of our resources.

Finally, with these tools in hand we can diverge into two sections, the general purpose mobile website, or an iPhone web application. Now by no means do I mean to downplay the power of the mobile website, I simply want to talk about something that’s less known, and that’s the iPhone Web Application.

So what is an iPhone Web Application

An iPhone Web Application in its simplest form is actually a website which is created with the same technologies web developers are already familiar with, but are created with the goal of emulating a native application on the iPhone.

HTML5, CSS3, Javascript, and CSS Webkit extensions provide a developer with rich tools to create power applications for an iPhone. Users can bookmark a web page to their home screen and right there, they can see one of the first signs of a web application, a custom home screen icon. Just like the application icon created for the home screen for a native iPhone application, through the use of Meta tags a developer can define a custom icon to be shown on the home screen for their web application. Furthermore, the developer can define another Meta tag which can hide the whole Safari UI including the address bar, and the navigation bar at the bottom of the screen. These are only some of the simpler things a developer can do.

Through javascript alone a developer has access to many of the events that an iPhone application developer would have, such as touch events, gesture events orientation changes, viewport settings and more.

Furthermore, the local storage engine, powered by SQLite, allows local databases to be created from a web application, which can be accessed through javascript. A popular example of local database storage is Gmail's offline mode, which uses the local storage to keep emails stored locally.

Not only can we create a local database on the user’s phone, we can work with more powerful caching functionality through the use of Manifest files which we can use to define a set of files to cache on the phone which can then be accessed later if the user tries to access the web application without an internet connection. So a developer can specify to cache CSS files and images to make sure the user enjoys the same UI experience while offline just like a native application. Manifest caches and the SQLite local databases are what I consider some of the most important tools at a developer's belt when writing an iPhone web application because it really blurs the line between an iPhone application and an iPhone web application.

Stay tuned as I plan to get into some more specifics relating to all aspects of iPhone web application development.