The Removal of background-position-y in Firefox, or why -webkit dominates

[Michael Morris]

At some point Mozilla pulled support for background-position-x and background-position-y citing they where never spec, breaking dozens of my sites on Firefox. All this crying and moaning about webkit dominating I'm starting to think is sour grapes. They don't want to innovate - they just want to feature kill and stagnate the web. It's one thing not to implement a feature, but to pull it? Between this action and Opera's decision to implement webkit I'm starting to wonder if these jokers even *care* if things work on their browsers anymore cause both those actions create headaches for me as a developer for no reasonable benefit.

Also, exactly how the hell are css sprites supposed to work in any position of the div but top left if you can't modify x and y independently. Idiots created an unfixable situation by pulling those attributes, and so in anger I won't be fixing those tags and I've pulled my -moz tags. If it wasn't for Firebug I wouldn't even use Firefox anymore.

[ralph.m]

how the hell are css sprites supposed to work in any position of the div but top left if you can't modify x and y independently.

Do you have an example of what you mean? Those x and y co-ordinates still work fine for me in Firefox, unless I'm missing the point.

[RyanReese]

At some point Mozilla pulled support for background-position-x and background-position-y citing they where never spec, breaking dozens of my sites on Firefox. All this crying and moaning about webkit dominating I'm starting to think is sour grapes. They don't want to innovate - they just want to feature kill and stagnate the web. It's one thing not to implement a feature, but to pull it? Between this action and Opera's decision to implement webkit I'm starting to wonder if these jokers even *care* if things work on their browsers anymore cause both those actions create headaches for me as a developer for no reasonable benefit.

Also, exactly how the hell are css sprites supposed to work in any position of the div but top left if you can't modify x and y independently. Idiots created an unfixable situation by pulling those attributes, and so in anger I won't be fixing those tags and I've pulled my -moz tags. If it wasn't for Firebug I wouldn't even use Firefox anymore.

I did a quick search on google for this as I've never heard of it. Why would you come to the conclusion they removed support of it??

[kohoutek]

Hmmm... to be honest, I don't see how separate x and y coordinate values is of benefit to positioning day-to-day elements, like sprites. It doesn't save any bytes, either.

The only place where I could see a slight advantage having separate xy coordinate values would be in a scenario where you'd have to use RTL in combination with images or icons. But even here, it's not really needed.

[TechnoBear]

At some point Mozilla pulled support for background-position-x and background-position-y citing they where never spec, breaking dozens of my sites on Firefox.

I certainly sympathise, but they are right. Those are attributes introduced by MS for IE and never were part of official specs. You can still position backgrounds using the standard background-position with the two co-ordinates - e.g. background-position: 10px 50px - so I don't see the issue here.

[Michael Morris]

The W3C is a joke. Half the items in the spec weren't spec until someone implemented it, and they finally caved. If all of computing moved at the rate of the W3C we'd just now be seeing the debut of the 6502 processor and the Atari 800 would be showing up sometime in 2024. They are anachronistic useless and deserve the abolition coming to them.

As for why the elements are imported, consider a button image positioned as follows.

.sample {
  height: 40px;
  width: 40px;
  background: url(path) top right no-repeat;
}

To save bandwidth the hover state of the image is 40 pixels down on the same image file (a sprite sheet). So on hover we simply go

.sample:hover {
  background-position-y: -40px;
}

The removal of the separate elements renders this approach impossible unless the image can be re positioned from the origin. The spec allows for this..

background-position: -40px right;

But *no* browser implements that - so don't give me the standards bs line.

[dresden_phoenix]

actually, the first value represents the x-coordinate. so what you would want is

background-position:  right -40px;

the only ( standards or no standards) reason advantageous bg-pos-y/bg-pos-x is not having to type two values. but honestly it (bg-pos-x) is equivalent to: background-position: (your value) (default. In a sprite situation you are looking through a 'keyhole' so
your element will always have at least ONE fixed dimension, and even in that case the sprite has to be clear in one direction or the other.

No big deal.

[Stomme poes]

Warning, much spew ahead:

Hmmm... to be honest, I don't see how separate x and y coordinate values is of benefit to positioning day-to-day elements, like sprites. It doesn't save any bytes, either.

The heck??? I would find this VERY useful! When all I want to do is shift a bg image down, it would be *really really really* nice to be able to just say that. Exactly as Michael showed:
.sample:hover, .sample:focus {
background-position-y: -40px;
}
Especially with a large sprite and on each element you've set a different LEFT value to show a different part on each element (like a single image for a menu). Right now you have to restate your lefts over and over and over again simply to move down a bit.

Heck, if developers everywhere are drooling over stuff like LESS and SASS because instead of using their text-editor's buffers to, with a single keystroke, add in all the -vendor prefixes, the CSS pre-processor will do it for them... or similarly making it easier for some people to change #008800 to #f3f3f3 everywhere in a stylesheet... then jeez the ability to HALVE the number of coordinates listed in a complicated sprite set should seem pretty obviously endorphin-inducing.

That said...

The W3C is a joke. Half the items in the spec weren't spec until someone implemented it, and they finally caved.

It's actually a requirement: two independent implementations (in browsers) on at least two environments (OSes). It's how the W3C works. It's how something like ARIA gets into the spec. And the specs they write aren't generally for you or me anyway. It's for Opera, Mozilla, IE, webkit, etc. The spec is written for the implementors, not the authors.

I certainly sympathise, but they are right. Those are attributes introduced by MS for IE and never were part of official specs.

Neither was embed, contenteditable, ruby-text or lots of other things. If it's a good idea and possible to implement in a sane way, they've shown they CAN do so.

Mozilla removes useful stuff all the time. They decide who uses their software and in what way. The only thing the rest of us can do about it is hope and pray someone's written a plugin to bring back in functionality removed (like this one).

I'm also not familiar with Mozilla ever supporting backgrounds x and y but if it was there and they removed it, then the discussion is on the mailing list somewhere.

But all the other browsers suck too, so we're doomed and that's that.

All this crying and moaning about webkit dominating I'm starting to think is sour grapes. They don't want to innovate - they just want to feature kill and stagnate the web.

Webkit has this nasty habit recently of just sneaking crap in without even telling anyone, then later after it's shipped posting a bloggitty to mobile devs "HEY LOOK NOW YOU CAN DO EVEN M0AR CRAZY ART-FART SH*T!" and leaving everyone else in a lurch. Besides, half the issue with everyone b*tching about webkit is THIS:

-webkit-some-retarded-feature: value;
-o-some-retarded-feature: ever-so-slightly-different-value-because-this-crap-is-still-in-TESTING;
-moz-some-retarded-feature: value;
-ms-some-retarded-featuer: IE's-version-of-value-just-for-giggles;

=== all show pretty much the same effect cross-browser, yet DEVELOPERS insisting on using experimental junk just go
"whooptie doo, look what I can do on an iThing!"
-webkit-some-retarded-feature: value;

Leaving out the other properties just so they can break everywhere. That's blood-boiling right there especially when it's some cutesy apple craptastic something where the HAWT-NEW-FEATURE allows users to, say, read white text on a white background, to use Bruce Lawson's example. So what do those poor saps using Opera's proxy browser because web developers ENJOY making ginormous American-super-size-me pages with 300kb of JS! for mobiles while proxy browsers make stuff SANE and affordable get?
Why, they get the white text on the white background. Lovely. Not because Opera didn't innovate that feature as much as webkit, but because developers are deliberately walking around with their ears plugged with overpriced Apple earbuds pretending all mobiles run webkit, and anyone else must be using a craptastic feature phone and we all know those people NEVER use the internets...

I'm sorry but that can be laid only at the feet of web developers who care as much about non-webkit as they care about anything else not in their immediate short-attention-span. These same people insist blinks don't internet. I could lose a lot of hair over this issue but I'll stop now.

[itmitică]

So let me get this straight: you want CSS to actually remember, inherit, pass over background position states for an image, for both x and y axes.

If that, I believe you're not seeing the big picture. This would require complex rules, involving inheritance, precedence, selectors specificity.

And what we have now about those above revolves around properties. Where as you suggest tying it all up to values, i.e. the background image itself.

That's something like making the value #fff the star instead of the actual color property: if a{} it's white I want a:hover{} white-rgb(10,10,10).

If it's this programmatic control that you seek, guess what: it can be done in SASS. The background-x or background-y and new color tones from those inherited, or from color variables. You can even automate the sprite process with Compass.

But I don't see how you could change CSS to do that and still stay true to its simplicity.

[Stomme poes]

So let me get this straight: you want CSS to actually remember, inherit, pass over background position states for an image, for both x and y axes.

They do that for all the other properties I'm not repeating on a change of pseudo-state.
border: 1px solid #f00;

thing:hover {
border-top-color: #c0ffee;
}

the other three borders are remembered without the browser breaking a sweat.
They can do this with overflow too: first only IE offered it, then they added it to CSS3, now I think just about everyone does it (overflow-y, overflow-x).

I mean, if THIS one can figure it out

then I figure the others have an idea they can try.


Also, the specs tend to have built-in assumptions. Like when you first position a background image, if you are silly and only state "left" then your top-bottom value should default to center (well, except in our special little browser there...). If the states can be listed separately, then the "default" is what you stated earlier.

That said, if it was in Gecko and they pulled it, I assume some issues came up that weren't worth the property. But without looking for the mailing list thread or the bugzilla, I'll never know.

Let me bring up the point again:
Let's say we have a menu using images which contain the anchor text, because someone wanted retardo fonts and this is pre-font-face era.

Especially with a large sprite and on each element you've set a different LEFT value to show a different part on each element (like a single image for a menu). Right now you have to restate your lefts over and over and over again simply to move down a bit.

This'll be a long-ass menu, 16 items. One sprite.
First item sets bg to 0 0
it's 100px wide so next list item sets bg to 100px 0
and it's 120px wide so the next item is set to 220px 0
and so on.

Now if ALL of them are to go down by 40 px on :hover, if you could target only the y axis, you could write ONE rule to hit them all:
tehanchors:hover, tehanchors:focus {
background-position-y: -40px;
}
but what you have today is, you have to list every item you mentioned earlier:
First item sets bg to 0 -40px
it's 100px wide so next list item sets bg to 100px -40px
and it's 120px wide so the next item is set to 220px -40px
and so on, 16 times.

I'm not saying we should use preprocessors for this, I'm saying if preprocessors are so darn popular because of making coding less, this should count as useful, shouldn't it??

[itmitică]

They do that for all the other properties I'm not repeating on a change of pseudo-state.
border: 1px solid #f00;

thing:hover {
border-top-color: #c0ffee;
}

the other three borders are remembered without the browser breaking a sweat.

Yes, because it's about the border property, it's not about the values for it: how #c0ffee is being somehow deducted from #f00, like he wants. Do you get it now?

You simply reset a value for a property, whereas he wants to deduct a value for a property from a previous selector, a state remembered... randomly so far. It's inheritance of *PART* of the property's values he's after, not resetting the value for a property, like you're doing with your border example, and it's based on the selector, property *AND* value.

Off Topic:


Mallory, I have a complain. It's not fair using shorthands when he's clearly specifying undetermined core properties. How does #f00 compare to url 'not-known-about.jpeg'? #ff0 is an entity, it doesn't have any 'tone-down' or 'tone-up' characteristics you could further set. No chocolate for you tonight.

Taking the sprites example a little further, it would be a little hard to retrace and predict (to fathom the exact position state), for all the elements and all the rules, where you shifted to center from left, and from center to right and all those again, and where you've gone to another row of graphics, throughout the whole style sheet, don't you think?

And what's the relation between elements and rules, and how this affects the current "pointer", or the current state of x and y axes for the sprite image and how are those dictating this "inheritance"? You'd need to account, like in plotting (BASIC days), where the current position for the plotter is. It get's pretty hairy.

My guess is you'd end up doing something like this:

? {
bkg-pos-y: -50px;
bkg-pos-x:-200px; }

?? {
bkg-pos-y: -70px;
bkg-pos-x:-40px;
}

[Stomme poes]

I see x axis and y axis as two different separate things, set with a property not unlike a shortcut (ie, background). That something is 4px from the left really has little to do where the top starts.

Watch, we do it all the time:

.box {
position: relative;
}
.boxChild {
position: absolute;
left: 0;
top: 14px;
}

.box:hover boxChild {
top: 0; //look ma, no LEFT!
}

If the position of a box relative to a parent is two independent axes, why would positioning a pixel-sized file relative to its parent be any different? Are these not the same principles??

[itmitică]

Well, it seems we're not on the same page: sprites. True, he talks about two states sprites, but you mentioned big sprites. Which can have graphics for more than one element and its hover or active or current states. Not all elements are nav, and not all sprites have only normal and hover states in them, for one element. That's not realistic, in an image you'll have sprites for random elements, without a strict parent-child hierarchy.

Sprites in an image are used randomly in a stylesheet, without any account, without following a strict parent-child hierarchy. Here you use a sprite for nav, there you use it for footer. Then you go and start treating various elements that can appear in body. Maybe you jump back to nav. Maybe to footer. And then back to body, in a section.

What he wants is CSS to be aware of the fact that what those few random elements are having in common, is not a property, but a value: url('img.png'). That's his ground zero. From then on, he wants to revolve around its use in the whole stylesheet, with a remembered state for its used coordinates.

Based on the fact that a group of random elements share the same image, he wants CSS to give him a rule, or, better yet, he wants CSS to accommodate him and guess how or devise a order in which a "pointer" is remembered after each use of this image for background, but without giving any guidelines. Not that giving any guidelines would make the task doable by CSS current mechanisms, without the programming support I was talking earlier.

Even more, if an algorithm were to be put in place, I'm not sure I would want to adopt something so complex in nature, because there's no doubt about that, it'll be complex, just because I don't want to pinpoint two exact coordinates and I'd rather guess one (read "inherit one" if you like it better). We all know where guessing will take you.

[kohoutek]

Warning, much spew ahead:



The heck??? I would find this VERY useful! When all I want to do is shift a bg image down, it would be *really really really* nice to be able to just say that. Exactly as Michael showed:
.sample:hover, .sample:focus {
background-position-y: -40px;
}
Especially with a large sprite and on each element you've set a different LEFT value to show a different part on each element (like a single image for a menu). Right now you have to restate your lefts over and over and over again simply to move down a bit.

Heck, if developers everywhere are drooling over stuff like LESS and SASS because instead of using their text-editor's buffers to, with a single keystroke, add in all the -vendor prefixes, the CSS pre-processor will do it for them... or similarly making it easier for some people to change #008800 to #f3f3f3 everywhere in a stylesheet... then jeez the ability to HALVE the number of coordinates listed in a complicated sprite set should seem pretty obviously endorphin-inducing.

The most complicated sprites I've made require nothing more than the use of relative positioning to prevent redundancy. You declare the coordinates that don't change for an element once, position it relative, set a top/bottom/left/right value and be done with it, then add variable values to whatever coordinates you want via background-position. That's perhaps not as neat, but I don't feel like what we currently have is limiting, at least for the scenarios I can imagine.

[Stomme poes]

You declare the coordinates that don't change for an element once, position it relative, set a top/bottom/left/right value and be done with it, then add variable values to whatever coordinates you want via background-position.

Since the method I use to position and move sprites always takes redundant redundancies with the coordinates, I'd love to see an example of how you do it. Might save me a bunch of code.

Do you mean to say you do something like
<li><a href="blah">some anchor<span></span></a></li>
Where a has set dimensions and overflow hidden, while span is actually set to size of sprite rather than size of a, and then you position (for example) left on the span and then use bg position only for vertical changes?