Do you have a test case that actually shows this as working in Gecko 1.9.2 + (firefox 3.6+) ? Because my testcases fail for both the -moz-background-position-* and background-position-* a€“ and the error console flags them as errors (tested with both fx 3.6 and the latest Minefield builds).

Jonathan Snook said on March 02, 2010

@Philippe: I have no idea how I managed to screw that up but I've updated the article to reflect the cold hard fact that I was wrong. Sorry.

philippe said on March 02, 2010

@Jonathan: Errare humanum esta€|
I was already paranoidly afraid that my goldfish had managed to cause all my computers to malfunction in some most bizarre ways. Glad that this is not the case :-).

Kit Grose said on March 02, 2010

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.

I disagree completely. Here's where it saves space:

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

.icon:hover { background-position-x: -30px; }
.icon:active { background-position-x: -60px; }

Which sure beats:

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

#a:hover { background-position: -30px 0; }
#b:hover { background-position: -30px -30px; }
#c:hover { background-position: -30px -60px; }

#a:active { background-position: -60px 0; }
#b:active { background-position: -60px -30px; }
#c:active { background-position: -60px -60px; }

Imagine that across an entire spectrum of sprites (usually many more than 3) and at the very least, it's not easy to keep track of the crap you're coding. Making a change (based on a change to the underlying art) is especially frought with danger.

petr said on March 03, 2010

Interesting is, that setting background position in JavaScript using jQuery, background positioning works just fine for me even in Firefox 3.0.10 and also in Opera 10.00. One my jQuery plug-in is relying heavily on background positioning and so far it is performing well everywhere I've tested.
Maybe jQuery performs some kind of magic under the hood to make it happen.

Piotr Petrus said on March 03, 2010

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.

I laughed out loud, because a€” sadly a€” this might be true. Thata€?s what happens when engineers dona€?t listen to designers when building a spec.

Andy Kinsey said on March 03, 2010

Love this explanation of how it works, i've recently experimented with background positioning on my site (click my name) - I find it works in most current browsers but even with the various scripts around nothing will get it to work in older browsers, its pretty much same story with multiple image backgrounds that i'm growing to love so much - by the way IE8 doesn't even support these never mind 7 or 6! Pfft

Jon Raasch said on March 03, 2010

Yeah I'm in your corner and have been clamoring for this as well.

Ryan Cannon said on March 04, 2010

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.

That's certainly true when your selector is #a {}, but when you're doing something like #doc .header .content-navigation li {} adding hover states and selected states then doing three rules each it starts to add up. Plus, managing those sprites is a nightmare.

Jason Grant said on March 09, 2010

I always get the x and y values the wrong way round initially when coding the background image into anything. :-)

Nicolas Chevallier said on March 09, 2010

Thanks for this little tips. I never thought about that but it will save me a lot of time for my new project!

Niels Matthijs said on March 10, 2010

"Admittedly, that didn't save us any bytes"

Hmmm, who cares. The point is that you didn't have to declare the same Y-value three times. If the Y-value changes you have to adapt it in three places, by being able to simply change the X-value, you gain control and there's less room for errors when adapting the css.

Nora Brown said on March 10, 2010

I'd love to have this feature as well. For large sprites, it would make the CSS much more compact and easier to manage.. C'mon Firefox!

Nicely implemented comment preview, by the way.

Jake said on March 13, 2010

It does actually work on Firefox, at least for me it does. Try a fresh install?

Dena said on March 18, 2010

I use sprites a lot for web sites with a lot of images so there can be minimal requests. But i think it's currently fine with current background-position property. In fact, i havent heard of this x-y thing before this article Jonathan :)

Russell Heimlich said on March 19, 2010

I wish background-posiiton-x and background-position-y were universal. They are such a good idea. Here is the perfect use case of where such a feature would come in handy. Instead I had to resort to much more bloated code for a card game that utilized sprites

Eva said on March 25, 2010

I concur Jonathan. So many times I've been frustrated to have to get both the X and Y value when i only need to alter one at a time. Shame it didn't pass w3c specifications. I'd love it to have cross-browser support...

Marton Sari said on March 28, 2010

+1. We need it. Inexpressibly blind those spec makers are...

Burton Radons said on April 03, 2010

I'm just banging my head on this issue myself and the very existence of it is absurd. There's no need for a "use case". background-position is a property with multiple values. It should be split, as every other property with multiple values should be, for the same reasons - because sometimes you need to splice CSS in interesting ways that can't be foreseen. If giving all compound properties single-property alternatives isn't policy for the design of CSS, then it must become so. Do not prescript.

This worthless issue has wasted hundreds of times the man-hours it would take to just put it in the standard and have Firefox implement it properly.

It doesn't work in FF 3.6.3 for me, and "-moz-background-position-[xy]" don't seem to exist. I'm not going to try a fresh install or anything like that because if it happens to me, it's going to happen to other visitors so I have to assume it's broken. I guess I'll just need to add ... 20x the cases, woo!

Benjamin Cordes said on February 05, 2011

Thank you so much! I've been cross-browser debugging my site and could not for the life of me figure out why Firefox wasn't honoring the "background-position-y" in my CSS file, and here I come to find it's not supported and all I need to do is remove the "-y" to get things working. Thanks again for inadvertently saving me hours I'd have otherwise spent doing countless Google searches; keep blogging!

Javier Albinarrate said on February 11, 2011

This feature is SOOOO much wanted, it is a pitty that it is not standard. Basically in my case I have a number of different bar styles (distributed horizontally one next to the other) with different discrete levels vertically stacked (lets say 5% 10% and so on).

If I could manage X and Y independently, then, one dimension (X) would be the bar style defined by a class, and the other dimension (Y) would be the percent of the bar.

So right now, I have to manually manage both X and Y as property... every time I want a BLUE bar... I have to lookup, what X corresponds to blue... that sucks.


Julian said on March 02, 2011

I'm running into a place where I need this - the use case is an element with a background coming from a sprite image. I always want it to hover to

background-position: (current) -20px;

but I can't see how to just change the Y position!

Kevin Rice said on March 16, 2011

FIREFOX WORKAROUND (sprite, 1-axis movement):

#a {background-position:0px 0px}
#a:hover {background-position:inherit -100px}

Use of 'inherit' appears to work fine, and inherits the non-hover position without having to re-write it. Mileage may vary.

Kevin Rice said on March 17, 2011


Testing error on my part. Apologies.

Aldo_MX said on March 31, 2011

Firefox developers are just neglecting to implement it because from their point of view it either breaks sites or breaks the spec, even with a vendor prefixed implementation:

Please people help adding votes to increase the importance of the bug.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.