Monday, April 12, 2010

CSS Sprites: What They Are, Why They're Cool, and How To Use Them

You’ve heard of them, but…

Do you really understand them? The name might be a little misleading, because sprites aren’t little images like you might be picturing, a sprite is actually one big image. Have you ever seen the CSS technique where the “on” and “off” states of a button are contained within the same image and are activated by shifting the background-position?

http://css-tricks.com/wp-content/csstricks-uploads/simple-css-sprite.png

Here is an example of that on CSS-Tricks.

Think of CSS Sprites as an extension of that technique. The difference is that instead of just two or three images being combined into one, you can combine an unlimited number of images into one. The origin of the term “sprites” comes from old school computer graphics and the video game industry. The idea was that the computer could fetch a graphic into memory, and then only display parts of that image at a time, which was faster than having to continually fetch new images. The sprite was the big combined graphic. CSS Sprites is pretty much the exact same theory: get the image once, shift it around and only display parts of it, saves the overhead of having to fetch multiple images.

Why combine all those images? Isn’t it quicker to have smaller images?

Nope, it’s not. Back in the day, everybody and their brothers were “slicing” images to make pages load faster. All that technique did was fool the eye to make it look like the page was loading faster by loading bits and pieces all over at once. Each one of those images is a separate HTTP-Request, and the more of those, the less efficient your page is.

Let’s look at a quote from the article “Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests” by Tenni Theurer on the Yahoo! User Interface Blog.

Table 1 shows popular web sites spending between 5% and 38% of the time downloading the HTML document. The other 62% to 95% of the time is spent making HTTP requests to fetch all the components in that HTML document (i.e. images, scripts, and stylesheets). The impact of having many components in the page is exacerbated by the fact that browsers download only two or four components in parallel per hostname, depending on the HTTP version of the response and the user’s browser. Our experience shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.

Table 1. Time spent loading popular web sites

Time Retrieving HTML

Time Elsewhere

Yahoo!

10%

90%

Google

25%

75%

MySpace

9%

91%

MSN

5%

95%

ebay

5%

95%

Amazon

38%

62%

YouTube

9%

91%

CNN

15%

85%

Every single image, whether it’s an <img> tag or an background-image from your CSS is a separate HTTP-Request, so you can image how quickly those requests can wrack up.

OK. So how is it done?

I thought you would never ask. Let’s start by showing the BEFORE example. Notice in the CSS below how the anchor tag does not get a background-image, but each individual class does.

#nav li a {background:none no-repeat left center}
#nav li a.item1 {background-image:url('../img/image1.gif')}
#nav li a:hover.item1 {background-image:url('../img/image1_over.gif')}
#nav li a.item2 {background-image:url('../img/image2.gif')}
#nav li a:hover.item2 {background-image:url('../img/image2_over.gif')}
...

example1before.png

Using CSS Sprites, we can really lighten this example up. Instead of having ten separate images for the buttons (five default states and five rollover states), we can literally combine all of them into one big long image. I won’t go into great detail about how this is done, I’ll just give you a basic walkthrough. Create a new image that is as wide as your widest image and and as tall as the combined height of all your images plus X pixels, where X is the number of images you have. Now place you images into this new image, left aligned, one on top of the other with one pixel of white space in between.

Now check out the AFTER example. Notice in the CSS that there is a single background-image applied to the anchor element itself, and the unique classes merely shift the background position with negative Y coordinates.

#nav li a {background-image:url('../img/image_nav.gif')}
#nav li a.item1 {background-position:0px 0px}
#nav li a:hover.item1 {background-position:0px -72px}
#nav li a.item2 {background-position:0px -143px;}
#nav li a:hover.item2 {background-position:0px -215px;}
...

example1after.png

We were able to reduce the number of HTTP-Requests by 9 and the total file size of the image(s) by 6.5 KB. That’s a pretty huge improvement for such a little example. Imagine what you could do on a full website.

 

Ugh. That sounds like a lot of work.

Just remember what Chuck Norris once said: “All great things require great dedication.” Actually I’m not sure if he said that or not, but it’s good advice anyway. But fortunately for you, there is a web service which makes creating and implementing sprites really easy. There are actually lots of different services designed to help you making sprites easier, but I think hands down, the best one is SpriteMe.

Using SpriteMe

SpriteMe is a bookmarklet. So after you’ve put it up in your bookmarks bar, just go to any website and click it. It will open up an overlay over the right side of your screen.

http://css-tricks.com/wp-content/csstricks-uploads/spriteme-1.jpg

The top white box is a list of all the background graphics on your page that it feels like could be combined into a sprite. The boxes below are graphics that probably won’t work for sprites (and it will tell you why). If you think differently, you can drag the links in and out of their boxes. Once you have all the images to be combined in that top box, just click the “Make Sprite” button. It will combine them all into a single image (a CSS Sprite!) that you can view right there.

http://css-tricks.com/wp-content/csstricks-uploads/spriteme-2.jpg

On the current design of this site, this is a (scaled down) version of the end result. (Or see the real thing)

http://css-tricks.com/wp-content/csstricks-uploads/sprite-example.png

Recently, SpriteMe also made it available to “export” the CSS. Click that button and you’ll see some code like this:

A id=home-link
{
  background-image: url(http://css-tricks.com/wp-content/themes/CSS-Tricks-4/images/logo.png)
  background-image: url(http://www.jaredhirsch.com/coolrunnings/public_images/3deb155981/spriteme1.png);
  background-position: -10px -10px;
}
A
{
  background-image: url(http://css-tricks.com/wp-content/themes/CSS-Tricks-4/images/nav.png)
  background-image: url(http://www.jaredhirsch.com/coolrunnings/public_images/3deb155981/spriteme1.png);
  background-position: -10px -56px;
}

The crossed out code is what used to be in your CSS, and what the replacement should be is below it.

What can’t sprites do?

They don’t do repeating graphics*. Sprites are for graphics that are just single blocks. Icons are a great example candidate for CSS sprites.

*OK, they kinda can do repeating, but it’s a little trickier and can only work one-dimensionally (x or y).

Either start from the beginning with Sprites, or do it all at the end

The using of sprites is a no-brainer. You should do it. But what is the workflow when creating a new design? I think you should go one of two routes. The first is to know that you are going with sprites from the get-go and built it as you go along. That means have a Photoshop file open, start from the upper left, and drop stuff in as you need it. If you have another icon (or whatever) that makes sense to put in a sprite drop it in there and resave it.

The other way, which perhaps makes even more sense, is to develop without thinking about sprites at all. Make everything separate individual graphics. Then when the site is “complete” (or at least, ready for release, we all know sites are never “complete”), then use SpriteMe and do the spriting then.

 

Monday, April 5, 2010

IE9 Platform Preview available

IE9 Platform Preview available

In November last year, Microsoft revealed some of what will be new and improved in Internet Explorer 9 in the IEBlog post An Early Look At IE9 for Developers.

Today, IE General Manager Dean Hachamovitch posted a follow-up: HTML5, Hardware Accelerated: First IE9 Platform Preview Available for Developers. Yes, you can now download what Microsoft calls a Platform Preview to test drive Internet Explorer 9 for yourself.

There are also a number of demos to show the improved performance and standards support in IE 9. Judging by several of the demos (HTML5 T-Shirt Designer and SVG-oids are two) it looks like IE9 will finally support XHTML served with the application/xhtml+xml media type. We’ll never know, but I can’t help wondering if the number of people using “real” XHTML would have been greater if Microsoft had implemented support for that earlier.

One of the things that Microsoft claims will be improved in IE9 is type rendering, which I’m looking forward to a lot. To my (admittedly Mac OS X-conditioned) eyes the whole of Windows needs to catch up there.

As Jeffrey Zeldman puts it in IE9 preview:

Thus efforts to catch up to the typographic legibility and beauty of Mac OS X and Webkit browsers are presented, in Dean Hachamovitch’s blog post, as leading-edge innovations.

Type rendering aside, it’s promising to see more information about IE9. Let’s hope Microsoft can live up to what Dean Hachamovitch writes in today’s blog post:

We want the same markup to just work across different browsers. In IE9, we’re doing for the rest of the platform what we did for CSS 2.1 in IE8. IE8 delivered a high-quality CSS 2.1 implementation, sticking to the standard, and looking to other implementations in places where the standard is ambiguous.

I’m still amazed at how few IE8 problems related to CSS 2.1 I have run into. If IE9 can deliver that level of support for HTML5, DOM, CSS3, and SVG… yay!

Makes me wonder how long it will take for IE8 to be phased out.

 

 

Thursday, April 1, 2010

sIFR default CSS hides content from at least one screen reader

Just a heads-up to anyone using sIFR to render text: the default CSS that comes with sIFR hides the replaced text from the VoiceOver screen reader. I don’t know if any others are affected – VoiceOver is the only screen reader I have been able to verify this problem in.

The culprit is the following rule:

  1. .sIFR-alternate {
  2. position:absolute;
  3. left:0;
  4. top:0;
  5. width:0;
  6. height:0;
  7. display:block;
  8. overflow:hidden;
  9. }

VoiceOver (or WebKit, not sure) figures that anything inside an element with those properties should not be displayed or spoken, so the end effect is pretty much the same as using display:none – the user won’t know that the text is there.

This is obviously a major issue for anyone using VoiceOver. Fortunately the following CSS can be used to hide the replaced text instead:

  1. .sIFR-alternate {
  2. position:absolute;
  3. left:-9999px;
  4. }

After this change, all screen readers I have been able to test with read the replaced text. So, if you use sIFR on any of your sites, please consider updating the CSS to avoid inadvertently causing problems for VoiceOver users.

 

Copyright http://www.456bereastreet.com/archive/201002/sifr_default_css_hides_content_from_at_least_one_screen_reader/