CSS Sprite Best Practices

October 27, 2009

We’re in the process of converting our web site to use CSS sprites to improve frontend performance. To implement CSS sprites, I’d recommend using SmartSprites. It’s a simple build-time tool that allows you to build your CSS using regular separate background images, annotate the CSS files using CSS comments, then run the tool and have it generate the CSS sprite image files and updated CSS files. It’s an excellent tool.

Unfortunately, due to limitations in the CSS sprite concept, SmartSprites can’t work with just any background image usage you already have. Here are a few pointers to keep in mind when building your CSS, to make sure it’s as spritable as possible.

  1. Don’t use CSS sprites pre-SmartSprites. This may sound obvious, but there are some reasons why you might end up with some CSS sprites before you use SmartSprites. For example, our design firm implemented hover states for UI elements as CSS sprites: the same image has normal and hover states, and a hover event just changes the background alignment. Also, we use YUI widgets, and some of their default styles use CSS sprites.

    The reason SmartSprites doesn’t work on existing CSS sprites is that it ignores your existing background positioning declarations. It assumes you have a single background image, includes that image in the sprite, then positions the sprite to show that one image.

    The workaround I used for this was to split out the smaller CSS sprites into individual images, which are then recombined by SmartSprites into the macro sprites.

  2. Separate out “background properties into “background-image.” SmartSprites requires background-image to be on its own line. It’s not too hard to refactor later, but if you can write the styles this way to begin with, you’ll save some time.
  3. Make sure repeating images are as few pixels as possible in the repeating dimension – preferably 1px. In order to get repeating sprites to tile properly, SmartSprites has to find the lowest common denominator of the image size. For example, if you have a 2px repeating image and a 3px one, it can’t just sprite them together, because then the 2px one would have a 1px empty row. And it can’t just repeat the first pixel of the 2px one, because the pattern might not tile properly. So it needs to create a 6px image, repeat the 2px one 3 times, and the 3px one twice. 6px isn’t too bad, but if you add a few more images of different sizes, it can expand out of control.
  4. Whenever possible, make your background images cover the whole element, not just part of it. Don’t create a vertically-expandable div and style a background image to cover just the top of it – instead, create one div that’s the height of that background image, and style that. Remember, a CSS sprite is a bunch of images concatenated together, so you won’t get blank space below it: you’ll get more images. One way you can get around this is to take advantage of SmartSprites’ ability to organize the images either horizontally or vertically. If you append the images horizontally left-to-right, there won’t be anything below that header image, so you can still style it to cover just the top. One case where this won’t work, though, is in repeating sprites. If you have a horizontally-repeating sprite at the top of an element, then it’s difficult to put it in a sprite, because the only place to put other elements is above or below it, and the below ones will show up in the element.

JS Auto-Tab That Doesn’t Suck

July 7, 2009

Here’s a JavaScript auto-tab implementation that doesn’t have that most annoying of bugs: when you click or tab into a field that is already populated, it tabs to the next field, disallowing you from deleting or changing. This one only auto-tabs on keyup.

UPDATE: dag nabbit, I was wrong. Shift-tabbing back to the previous field doesn’t work right in Firefox. On the “var filter” line, add a 16 into the [0,8,9] list, making it [0,8,9,16], and you should be set.

Numeric Filename Sorting: Your Doin it Rite

July 28, 2008

I just noticed that Windows correctly sorts filenames that have ascending numbers, even when the numbers have different digit lengths and no “zero” prefixes:

Not sure how long that’s been in there, but it hasn’t always been. Good job for once, Microsoft!

Photoshop Prototypes

July 28, 2008

As part of the design process of the webapp project I’m currently on, I’m creating a prototype in Photoshop (actually, ghettoshop). Yes I know – not ideal. But they tell me it’s the best way to help the business owners get a feel for using the application, as a part of requirements elicitation. So I’ll create mockup screenshots, wire them together into HTML files that actually have the user click where they need to click, etc.

This process has been one big challenge to my perfectionism. Here are a few things I’ve learned so far:

  1. Get the general requirements nailed down as much as you can at first. If you find out you need another column in a table, you’ll need to rerender all of your screenshots.
  2. Group things so that you can hide or show a “step” with one click. I think I remember that Fireworks had a great way to do this by grouping layers into folders, which you could hide or show all at once. Photoshop probably has this too. The Gimp doesn’t seem to have it, so I’m having to make do by merging down into one layer per step. Reduces editability, but it’s a necessary evil.
  3. Don’t let the ugliness make you sad. The pixels will be off, and there will be artifacts and garbage. If there isn’t, you’re spending too much time on it for a prototype. As long as it looks like a web page to the users, and lets them click through, it’ll meet the goals.

GIMP Image Editor Fails at Fixed-Ratio

July 25, 2008
GIMP Image Editor Fails at Fixed Ratio

GIMP Image Editor Fails at Fixed Ratio

The Qwerty Principle

July 23, 2008

Has anyone already come up with this principle?

If I understand it correctly, the Qwerty keyboard layout was designed for mechanical typewriters to slow typers down, because fast typers would jam the typewriter. When computers came along and jamming was no longer an issue, everyone already knew qwerty, so the inefficient layout was preserved (in contrast to, for example, more efficient layouts like Dvorak that nobody knew).

So the Qwerty Principle would be, usability doesn’t happen in a vacuum. If people are already used to a paradigm that is “unusable,” that fact may itself make the paradigm actually more usable, as compared to alternatives which are theoretically more usable.

You can see this in OpenOffice. Because everyone is used to MS Office, OpenOffice mimics MS Office’s poor/confusing menus and dialogs. GIMP could probably benefit from this by more closely mimicing Photoshop’s keyboard shortcuts.