Bug 16935 - Acid3 expects <html> margins to not affect absolute positioned elements
Summary: Acid3 expects <html> margins to not affect absolute positioned elements
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Dave Hyatt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-19 01:11 PST by Eric Seidel (no email)
Modified: 2008-01-21 14:56 PST (History)
2 users (show)

See Also:


Attachments
test case (383 bytes, text/html)
2008-01-19 01:13 PST, Eric Seidel (no email)
no flags Details
Update a couple of spots in RenderLayer that were missed. (19.23 KB, patch)
2008-01-19 13:34 PST, Dave Hyatt
hyatt: review-
Details | Formatted Diff | Diff
Here we go. Easy after all. (1.65 KB, patch)
2008-01-19 13:39 PST, Dave Hyatt
hyatt: review-
Details | Formatted Diff | Diff
Finally. (1.02 KB, patch)
2008-01-19 13:40 PST, Dave Hyatt
oliver: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-01-19 01:11:16 PST
Acid3 expects <html> margins to not affect absolute positioned elements

See the @font-face test (the map::after generated content).

Hixie claims that:
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

justifies that absolute positioned elements should ignore margins on <html>.  I tried to build a test case, but I couldn't get a <div style="position: relative; left: -20px; top: -20px;" to actually move itself up into the margins of the HTML (I could get it to move left into the left margin).

FF seems to behave identically to us in this regard.
Comment 1 Eric Seidel (no email) 2008-01-19 01:13:00 PST
Created attachment 18540 [details]
test case

I changed my test case to not use position: relative.  If I'm reading the spec correctly, this test case should show a single green 100x100 rect at 20px,20px.
Comment 2 Dave Hyatt 2008-01-19 10:59:56 PST
Hixie's correct.
Comment 3 Dave Hyatt 2008-01-19 11:00:34 PST
I'm actually surprised we don't handle this correctly.  We made a change for Safari 3 to really use the ICB for positioned elements.

Comment 4 Dave Hyatt 2008-01-19 13:34:13 PST
Created attachment 18553 [details]
Update a couple of spots in RenderLayer that were missed.

Unfortunate.  Our change in Safari 3 was incomplete.  RenderLayer still incorrectly halted at the root element.
Comment 5 Dave Hyatt 2008-01-19 13:36:48 PST
Comment on attachment 18553 [details]
Update a couple of spots in RenderLayer that were missed.

Actually never mind.  CSS2.1 states that the root element establishes a stacking context.  This is kind of weird, since it means positioned objects are positioned relative to the ICB, but in terms of stacking context they are sorted in the root (<html>'s) stacking context.

This means we'll probably just have to add in some kind of positioning hack when painting and hit testing for this case.
Comment 6 Dave Hyatt 2008-01-19 13:39:25 PST
Created attachment 18554 [details]
Here we go. Easy after all.

The enclosingPositionedAncestor method is all that needed updating.  It is used when converting to the right layer coords, and it was incorrectly allowing the root to be a positioned ancestor.

I will use the test case from the bug as the layout test.
Comment 7 Dave Hyatt 2008-01-19 13:40:07 PST
Comment on attachment 18554 [details]
Here we go. Easy after all.

Oops, I've been attaching the wrong patches this whole time.
Comment 8 Dave Hyatt 2008-01-19 13:40:49 PST
Created attachment 18555 [details]
Finally.
Comment 9 Oliver Hunt 2008-01-19 13:52:19 PST
Comment on attachment 18555 [details]
Finally.

i would argue that the change to RenderLayer::stackingContext is both unnecessary, and results in less clear code.
Comment 10 Oliver Hunt 2008-01-19 14:01:14 PST
Comment on attachment 18555 [details]
Finally.

r=me, though i'd like it if you could make a layout test :D
Comment 11 Dave Hyatt 2008-01-21 13:20:55 PST
Fixed in r29696.

Comment 12 Eric Seidel (no email) 2008-01-21 14:56:03 PST
The part of Acid3 which tests this still seems a few pixels off (absolute positioning of generated glyphs).  I'll file a separate bug about that.  Thanks for fixing this Dave.