53106 2011-01-25 11:48:55 -0800 CSS 2.1 failure: containing-block-032 - abspos children of an inline relpos element don't position correctly. 2011-03-14 14:54:17 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) PC OS X 10.5 RESOLVED WORKSFORME http://test.csswg.org/suites/css2.1/20110111/html4/containing-block-032.htm P2 Normal --- 47141 1 tabatkins webkit-unassigned hyatt ojan simon.fraser oldest_to_newest 339795 0 tabatkins 2011-01-25 11:48:55 -0800 According to <http://www.w3.org/TR/CSS21/visudet.html#containing-block-details>, when an inline LTR element is the containing block for an absolutely positioned element, the 'left' and 'top' properties use the left and top edges of the first box generated by the containing block, while the 'right' and 'bottom' properties use the right and bottom edges of the last box generated by the containing block. In the linked test case (note: must have the Ahem font installed), the "left" edge is just to the left of "B", while the "right" edge is just to the right of "C". This means that #topleft should cover B, #topright should cover A, #bottomleft should cover D, and #bottomright should cover C. Instead, #topright is covering the upper space, and #bottomright is covering the bottom space. By inspection, it appears that we're moving the "right" edge to be equal to the "left" edge, likely because we have a check somewhere that attempts to ensure that the "right" edge is never to the left of the "left" edge by setting them equivalent when that occurs. 340040 1 tabatkins 2011-01-25 17:28:39 -0800 We may be changing the spec here to make this behavior conformant. But if it turns out to be easy to fix, go for it. 367230 2 tabatkins 2011-03-14 14:25:43 -0700 The CSSWG resolved Issue 215 concerning this bug <http://wiki.csswg.org/spec/css2.1#issue-215> by making the containing block undefined in this case. So, no change required! 367266 3 simon.fraser 2011-03-14 14:54:17 -0700 Not for CSS2.1 at least...