Every now and then I look at using background-position-x and background-position-y but can never seem to find a definitive and up-to-date resource. To save myself the trouble in the future, I'm documenting it here.

Positioning via separate X and Y values is a feature that Internet Explorer introduced but never made it into a W3C specification. Any recommendations to add it to the spec have been denied.

Why have separate X and Y values?

I believe that there are several reasons why you may wish to have separate values.

Animation

The last time I was frustrated by the lack of consistent cross-browser support for X/Y was when I wrote my article on animating background images using jQuery. Having to take a string value, split it into its separate X and Y values, parse the units, and then rebuilding the X/Y value into a single string is a cumbersome experience. Being able to animate just the X or Y value would have been much simpler and would have worked with jQuery "out of the box", since jQuery already knows how to animate pixel or percentage-based values.

Sprites

CSS Sprites have become a popular way to optimize the performance of a page. It's an interesting technique in which you compile numerous background images into a single image and then use background-position to only show the desired part of the image on an element.

#a { background: url(sprite.png) 0 0 no-repeat; }
#b { background: url(sprite.png) 0 -30px no-repeat }
#c { background: url(sprite.png) 0 -60px no-repeat }

Of course, we could optimize this like so:

.icon { background: url(sprite.png) 0 0 no-repeat; }
#a { background-position: 0 0; }
#b { background-position: 0 -30px; }
#c { background-position: 0 -60px; }

However, given access to separate X and Y values, we could optimize it like so:

.icon { background: url(sprite.png) 0 0 no-repeat; }
#a { background-position-y: 0; }
#b { background-position-y: -30px; }
#c { background-position-y: -60px; }

Admittedly, that didn't save us any bytes and for this reason alone, I can see why the W3C denied the inclusion of this into the specification.

Internationalization

However, let's take a look at internationalization. Specifically, in having to deal with right-to-left (RTL) environments like Arabic. In these scenarios, where an icon is positioned on the left of some text in a left-to-right environment (LTR), the icon should now be positioned on the right.

Wouldn't it be great to just add in an extra line in bidi environments where we tell the background of all sprites to be positioned on the right instead of the left?

html[dir=ltr] .icon { background-position-x: 100%; }

That's it. One line. (And this actually works in IE7+, S3+ and Chrome.)

Instead, without the ability to separate X and Y values, all sprites need to be redeclared for RTL environments.

Support Table

Finally, here's the support table for which browsers support background-position-x and background-position-y.

Opera is the only hold-out at this point and hopefully we'll see it get introduced at this point. It has become a de facto standard and it's exclusion from the W3C specification doesn't diminish it's usefulness.

I'm embarrassed. I could've sworn I had it working in the latest version of Firefox but I've re-run my test case and I can't get it working in Firefox at all. My apologies for poor testing. But I'd still like it in all browsers, pretty please!

Logo Design Love is a book written by David Airey that covers the whys and hows of brand identity development.

The book is broken down into three parts: The importance of brand identity, the process of design and keep the fires burning which looks at how to find motivation and inspiration. It's a light 200 pages with readable type and plenty of examples.

David Airey aims this book at the aspiring designer by not only covering the design process but also covering the process of project scope and client management in the context of logo design.

Logo Design Love hits the mark when it speaks from experience, which it does for most of the book. There's plenty of real world examples with plenty of input from designers other than just Airey himself. The book falters only slightly (and briefly) when Airey makes assumptions or raises open questions as he does with his assessments on the Tropicana or New Coke campaigns.

In the end, Logo Design Love was an enjoyable read with plenty of good information in a well-designed package.

CSS3 features are making their way into the various browsers and while many are holding off on implementing them, there are those who are venturing ahead and likely running into a world of interesting quirks across the various platforms.

Two such features that I have been having the pleasure of enjoying are the use of multiple backgrounds and CSS gradients. I'm covering both features because multiple backgrounds by itself is simple enough, as are CSS gradients, but combining the two is where things get interesting.

Multiple Backgrounds

What are multiple backgrounds when it comes to CSS? I mean the ability to define more than one background image for a single element. That sounds wonderful, doesn't it? It is. No more having to have nested elements with lots of CSS just to create a layered effect. The syntax is very straightforward: just separate each background image with a comma.

background-image: url(…), url(…);

For browsers that don't recognize multiple backgrounds, the entire background declaration will be ignored. (Actually, according to PPK, Explorer Mac will show the last background declared.) Depending on your design, you may need a single image declared and then declare the multiple background on the next line.

background: url(…) 0 0 repeat 10px 100px, url(…) 5px 5px no-repeat 5px 5px #FFF;
background-image: url(…), url(…);

You can declare multiple backgrounds using the shorthand syntax, as well.

background: url(…) 0 0 repeat, url(…) 5px 5px no-repeat #FFF;

I threw a bunch of stuff in here to see if you're paying attention. The shorthand syntax for a normal background includes image, position, and repeat. However, the colour is always the last thing declared. (I've traditionally always declared it first.) There can only be one colour applied to an element—although with rgba, if you could declare the colour more than once, it'd theoretically be possible to mix colours.

Background Size

Another interesting property that is being implemented in recent browsers is support for background size. Any browser that supports multiple backgrounds also supports background size.

When declaring background size for multiple backgrounds, the declarations are separated by commas just like with background-image.

background-image: url(…), url(…);
background-size: 10px 100px, 5px 5px

In Opera, Mozilla, and Safari, you'll need to declare the vendor prefixes. Chrome and the Opera 10.5 dev builds don't require the vendor prefix. And to further clarify, background-size support is in Opera 10.1 but multiple background support isn't.

-o-background-size: 10px 100px; 
-moz-background-size: 10px 100px, 5px 5px;
-webkit-background-size: 10px 100px, 5px 5px;

(As much as I love the features that browsers are implementing, I'm getting really annoyed at all the vendor prefixes. Seriously. And believe me, by the end of this article you'll see how much worse it can get.)

The background size declares width first and then height. Technically, you should be able to omit the second value, which should use auto for the second value.

background-size: 10px; /* should be the same as '10px auto' */
background-size: 100%; /* should be the same as '100% auto' */

The reality?

There are two other values that can be used for background-size: contain and cover. Cover will make sure that the background image covers the element. Contain makes sure that the entire background image is visible within the element. Only Safari seems to be the odd man out on this one.

If you declare multiple images using the shorthand syntax, the background size is always declared after the background position (since they could technically be confused with each other) and separated with a slash.

background: url(…) 0 0 / 10px 100px repeat, url(…) 5px 5px / 5px 5px no-repeat #FFF;

The only problem is that no browser supports this and the entire background declaration will be thrown out if you try and use this syntax. Well, except for Opera 10.5 which does a weird thing where it ignores just the parts of the declaration it doesn't understand.

All this to say that you must always declare background size using the long form. In my opinion, this will almost likely always be the case... changing background implementations risk backwards compatibility and that's a hell I'd like to avoid.

CSS Gradients

One of the many cool CSS additions to come out of Webkit is the ability to specify gradients. Whereever you would normally specify an image using a url() syntax, you can specify -webkit-gradient instead. Probably the most likely scenario will be for background images but you could use it for border-image or list-style-image, too.

background-image: -webkit-gradient(linear, 0 top, 0 bottom, from(#496178), to(#2E4960));

The syntax takes a gradient type as the first parameter: linear or radial. The next two values indicate the start and stop points of the gradient. Each parameter after that is a color-stop(x, y) function where x is a percentage or a value between 0 and 1 and y is the colour value. from and to are shortcuts for color-stop(0, y) and color-stop(1, y) respectively. This implementation mirrors the functionality within the canvas specification.

CSS gradients have made their way into the W3C as a draft spec, although the syntax is different from how Webkit has implemented it. Firefox 3.6 has just been released and now includes CSS gradients using this newer syntax which separates the two types of gradients into their own syntax: -moz-linear-gradient and -moz-radial-gradient.

background-image: -moz-linear-gradient(90deg, #496178, #2E4960);

The first parameter is the position or angle. There are a number of ways that the shorthand can be calculated and degrees are likely the easiest to use. If you're doing a gradient from top to bottom, the angle can be ignored altogether and the colour stops are all that need to be specified.

background-image: -moz-linear-gradient(#496178, #2E4960);

There's no need to specify the color-stop, from or to functions like with the webkit gradients. You can specify multiple colour stops and it'll create a gradient between each one. If you wish to adjust the position of where the gradient transitions, you can specify it as a second value with the color stop.

background-image: -moz-linear-gradient(#496178, #323232 20%, #2E4960);

You can also use rgba values, too, if you wanted to create semi-opaque gradients.

Mixing the Ingredients

Now that you know how the two things work, let's look at putting it all together. If you want to do multiple backgrounds and use CSS gradients, you'll need to do something like the following:

background-image: url(…);
background-image: url(…), -webkit-gradient(linear, 0 0, 0 100%, from(#FFF), to(#000));
background-image: url(…), -moz-linear-gradient(#FFF, #000);
background-size: 10px 100px, 5px 5px;
-o-background-size: 10px 100px;
-moz-background-size: 10px 100px, 5px, 5px;
-webkit-background-size: 10px 100px, 5px 5px;

Remember when I said the other browsers ignore the entire declaration? That's right, if Firefox doesn't like -webkit-gradient (because it has no clue what it is), it'll pretend that the entire background shorthand was never declared. Opera 10.5 alpha will still recognize any url() declarations and just ignore the -webkit-gradient and -moz-linear-gradient statements. I've put in a bug report with Opera to change their behaviour to match what the other browsers do in this situation.

I'm also going to take a moment right now and rant about vendor prefixes. Yes, I know I mentioned it before but this is getting absurd. Honestly, my plea to Microsoft is to avoid jumping on this CSS3 bandwagon until specifications settle. Where they have, nail it to a tee and make sure it matches how other browsers do it. Don't be innovative.

Wrapping it up

Having been working with CSS gradients as of late, I really wanted to document the current state of things. As you can see, some features can offer up a bumpy ride when you want cross-browser compatibility (even if we are still ignoring the elephant in the room: Internet Explorer).

Check out the Demo Page

I had noticed this little bug on my own site. In the footer, there's a 5px border with the colour set using rgba. In Safari, it's as if the semi-transparent borders overlap each other in the corners and the values are compounded. This creates little squares in the corner of my squares.

Not quite what you'd expect. Firefox and Opera (10.5; I didn't test in 10.10) render this as you'd expect, with a consistent colour surrounding the block.

In testing some other border handling, I noticed that the overlapping only seemed to happen when the border colour was the same on all sides. If the border colour is the same but the border width is different, you'd still get the overlapping values in the corner.

Now, how far apart do the colour values need to be before it reverts to a different way of rendering the borders: generally 3/1000th of a difference.

With the following CSS, the borders render closer to expected in Safari:

border-color:rgba(0,0,0,.201) rgba(0,0,0,.204);

You can still notice a slight line at each edge as I suspect some anti-aliasing is at play. This is consistent between both Safari and Chrome, since they're both based on Webkit.