Bug 18013 - Margin auto: difference between centered divs and images in body background
Summary: Margin auto: difference between centered divs and images in body background
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://www.xs4all.nl/~jjj/webkit_marg...
Keywords: InRadar
: 14956 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-22 06:19 PDT by Jan Boeijink
Modified: 2011-07-15 15:48 PDT (History)
5 users (show)

See Also:


Attachments
A simpler test case that makes the problem more obvious. (58 bytes, text/plain)
2011-07-15 15:48 PDT, Ian Storm Taylor
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Boeijink 2008-03-22 06:19:28 PDT
Please follow the link, this makes it clear immediately. 
We have a horizontally centered div and a centered image in the body background. When scaling the window smaller than the background image width, a 1px gap becomes visible. Apparently when the image is larger than the window, it's not perfectly centered? This works perfectly in Firefox.
Comment 1 Jan Boeijink 2008-03-22 06:25:22 PDT
After posting the bug, I noticed that while the gap is not visible in FF, the background image is still moved when making the window smaller, not similar to Safari. I'm not sure which behaviour is better.
Comment 2 Scott Hulbert 2009-04-06 20:55:12 PDT
I have found this bug troubling and it is widely complained about online with no known solution. 

The issue seems to stem from background-position: center [y]; rounding differently than margin: [y] auto; when a window is an odd width. This can cause serious visual alignment issues unless the same centering method is used for the entire page.
Comment 3 stevethepocket 2010-12-06 15:14:18 PST
I am using Windows 7 and have noticed this bug in both Chrome 8.0.552.215 and Safari 5.0.3. I downloaded the latest WebKit build (r73302) as per the recommendation and saw that it still has the problem. Curiously, my boss, who has a Mac, said over Skype that he's not experiencing it.

A lot of developers, including myself, use a combination of background-align:center and margin:auto for centered backgrounds, so getting them to play nice with each other is fairly important. To the point of being worth fixing in an automatic patch rather than waiting for Safari 6.

Curiously, this only happens when the window is wider than the background image. They both scale correctly from that point down. If you visit the link, shrink the window down to be narrower than the background, and start stretching the right edge of the window one pixel at a time, you can see the background uncover one pixel, then move right one pixel, then uncover, move, uncover, move, then move again when you get to the 1025-pixel mark. Very odd.
Comment 4 Mark Rowe (bdash) 2011-01-17 14:13:54 PST
<rdar://problem/8875207>
Comment 5 Eric Celeste 2011-02-02 19:56:22 PST
There is a nice description of this bug at http://www.hackvalue.nl/en/article/85/off-by-one_errors_in_background_placement_in_web_browsers with an even simpler example http://www.hackvalue.nl/bug.html available.

I have noticed that this bug can also result in a one pixel VERTICAL offset when using Mobile Safari (AppleWebKit/533.17.9) on iOS.

Using a wrapper div with the background-position exhibits the bug (both horizontal and vertical):


   background-image: url(images/rea-back.png);
   background-position: center top;

Using a wrapper div with the margin auto resolves the bug (both horizontal and vertical):

   background-image: url(images/rea-back.png);
   width: 1020px;
   margin: 0px auto;
Comment 6 Eric Celeste 2011-02-02 20:01:40 PST
By the way, this seems to be the same bug reported as Bug 14956.
Comment 7 Dominic Cooney 2011-06-25 07:45:59 PDT
*** Bug 14956 has been marked as a duplicate of this bug. ***
Comment 8 Ian Storm Taylor 2011-07-15 15:48:29 PDT
Created attachment 101059 [details]
A simpler test case that makes the problem more obvious.

Why has this still not been fixed after being reported 3 years ago?

All other rendering engines handle this case appropriately.