Background Image Positioning Bug | May 3, 2005
A few months ago I was building a navigation menu using a list. I’d created a nice little arrow bullet which I wanted vertically centred and indented by 10 pixels. Pretty simple stuff I though, I’d just do something like this.
background: url(images/arrow.gif) no-repeat 10px center;
However when I checked, neither Safari or Netscape were displaying the image. I played around a bit and realised that these browsers refused to display the background image if I mixed units with keywords – something that’s allowed in the spec. This wasn’t a huge problem as I could simply do this:
background: url(images/arrow.gif) no-repeat 10px 50%;
So I noted the issue down and promptly forgot about it.
Browsing my “To Blog” list last week I came across the issue again and thought it was worth sharing. I knocked up a quick test case and ran it through browsercam.
All the versions of Netscape I tested failed to display a background image when I mixed keywords and units in the background property. The same was true for Opera 7. Opera 6 however displayed the background image but incorrectly centred it horizontally. Older version of Safari also displayed the bug, but it seems to have been fixed in the latest release.
Using the background-position property proved slightly better.
background: url(images/arrow); background-repeat: no-repeat; background-position: 10px center;
Safari 1.2 now displayed the background image correctly as did Netscape 7.2. Netscape 6.2 and 7.1 along with Opera 7 displayed the image but didn’t try to position it.
It’s not a particularly interesting or important bug, and is one that’s easy to avoid by not mixing keywords with units. However I thought I’d mention it just incase anybody comes across the same issue and wants a bit of a sanity check.
Comment
I wrote about this in Do not combine a length with a keyword on ‘background-position’ at the start of this year…
Comment
I launched your test case and using Firefox 1.0.3 I can see all background images (arrows) positioned as set in CSS above them.
Comment
I ran across the same issue once and just sort of made a mental note to not mix them again.
As far as I know it is proper CSS to mix the values like that, so I am not sure why Safari and Netscape are messing it up.
Comment
Thanks dusoft. You’re right, FireFox does play ball. I tested about 20 Browser/OS combinations and the problem mostly occurs in Netscape, Opera and older versions of Safari.
Comment
How good is browser cam? Wish i had seen that earlier!
Comment
I also ran into this a while back and after a bit of head-scratching I found that it’s as spec’d in CSS1. It plainly says “Keywords cannot be combined with percentage values, or length values” though it’s easy to miss. I think it’s only been somewhat recent that browsers started to enforce it.
Comment
Interesting. CSS 2.0 is the same. I guess it must have been changed in CSS 2.1 to reflect that the majority of browsers accept mixing keywords with percentages. So it’s actually not a bug but correct – if somewhat nonsensical – behaviour.
I have to admit that I tend to check issues I have with CSS 2.1 even thought it’s still “work in progress”. However this serves as a reminder that I should also check things against CSS 2.0 as well before jumping to conclusions.
Comment
Looking at the 2.1 spec, it says “For combinations of keyword and non-keyword values, ‘left’ and ‘right’ may only be used as the first value, and ‘top’ and ‘bottom’ may only be used as the second value.” Which, after reading it four times to make sense of it, does imply that “10px center” is forbidden.
Seems like a rather arbitrary rule to me. If “center” is simply equivalent to “50%” why can’t we use that keyword? Stupid standards bodies and their stupid standards!
Comment
Wait a minute, after reading it two more times upon posting, NOW it makes sense. It’s simply saying you can’t use “top” for a horizontal position, nor “left” as a vertical position, to which I reply “duh.”
So… yeah, “10px center” should be legal, it’s just inconsistently supported (shock, surprise). Rule of thumb remains: “don’t mix keywords and lengths/percentages.”
Comment
Another rule of thumb: Don’t misspell your image name. I spent 15 minutes shouting at all my browsers for being stupid before I realised my stupidity. :S
Comment
Uhm… I might be wrong, but I think there’s a difference between “50%” and “center”… 50% lets the image start half way from the top, while center should take the image’s height into account and “really” center it, I guess. I’m just too lazy to try and see if there’s any difference right now…
Comment
Sorry, slightly off topic…
>> Don’t misspell your image name.
Tell me about it! My spelling is pretty awful at times and its bitten me several times too!
I actually have a whole application i wrote about 2 or 3 years ago where i have consitently spelt a widely used variable wrong… I only noticed after shouting at a bit of modified code recently… :( GAH!
Comment
Quirksmode has a pretty good compatibility chart. Although it only addresses Safari 1.3.
Comment
David: 50% also takes the image dimensions into account, so it behaves identically to the “center” keyword as far as I can tell. “left top” is equivalent to “0 0” and “right bottom” is equivalent to “100% 100%”.
Comment
hi andy,
this is post is very very good,
god bye.
Comment
Craig: wow. didn’t know that. Thanks! :)
Comment
I ran into this issue when building this site: http://www.bbagroup.com, with the additional complication that browsers can’t agree where to put a background image when the text breaks over two lines - in the end I had to declare a different position for wrapped list items and tweak the dimension to average out the positioning. I wish I’d seen this post or one like it before struggling with why mixing numbers and words didn’t work.
thanks
Comment
David: Actually, what happens is that when you specify a percentage, say 10%, then the point 10% down (or across) the image will be 10% down (or across) the page .
Comments on: Background Image Positioning Bug
Jump to the comment form