53140 2011-01-25 16:07:05 -0800 CSS 2.1 failure: dynamic-top-change-005 fails 2012-02-19 02:58:42 -0800 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) PC OS X 10.5 RESOLVED DUPLICATE 69210 P2 Normal --- 68149 69210 47141 1 simon.fraser robert hyatt robert simon.fraser tabatkins oldest_to_newest 339999 0 simon.fraser 2011-01-25 16:07:05 -0800 http://test.csswg.org/suites/css2.1/20110111/html4/dynamic-top-change-005.htm 340001 1 simon.fraser 2011-01-25 16:15:05 -0800 Maybe we get containing block wrong for relpos inline inside relpos inline? 340003 2 simon.fraser 2011-01-25 16:17:41 -0800 We're also failing to re-layout on the dynamic change. 340308 3 simon.fraser 2011-01-26 09:32:51 -0800 Part of the issue is with top: inherit not causing layout when the inherited value changes. 340311 4 simon.fraser 2011-01-26 09:33:58 -0800 (In reply to comment #3) > Part of the issue is with top: inherit not causing layout when the inherited value changes. This issue seems fixed on TOT. 469197 5 107799 robert 2011-09-18 15:11:13 -0700 Created attachment 107799 Reduction This is a reduction of the issue, though I'm not 100% sure it is an issue. dynamic-top-change-005 expects a relatively positioned originally inlined block-display child of a relatively positioned inline parent to render relative to the parent. So in the case of the reduction, it should render 75px relative to the top of the view. Firefox does this, but WebKit and Opera render 25px relative to the top of the view. The reason WebKit does this is because the parent and child are in fact sibling render layers rather than parent and child, which is a result I guess of handling a block inside an inline flow. So is this an wanted side-effect of the 'All in-flow children of an inline flow must be inlines.' rule, or is the test wrong-headed in the first place? 469199 6 robert 2011-09-18 15:34:10 -0700 It really does look like the test expects the relpos block to offset 50px from the inline parent rather than the nearest containing block, which is the 'grandparent'. Is that really the expected behaviour of a relatively positioned block? 475624 7 109192 robert 2011-09-29 12:59:53 -0700 Created attachment 109192 Easier to understand reduction This makes the issue (as I see it) easier to see - there is no red if the relpos inline block calculates its offset from the relpos inline parent. 559892 8 robert 2012-02-19 02:58:42 -0800 *** This bug has been marked as a duplicate of bug 69210 *** 107799 2011-09-18 15:11:13 -0700 2011-09-18 15:11:13 -0700 Reduction relativeparentandchild.htm text/html 395 robert PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEvL0VOIiAiaHR0cDov L3d3dy53My5vcmcvVFIvaHRtbDQvc3RyaWN0LmR0ZCI+CjxodG1sPgogPGhlYWQ+CiAgPHN0eWxl IHR5cGU9InRleHQvY3NzIj4KICAgICNwYXJlbnQgeyBwb3NpdGlvbjogcmVsYXRpdmU7IHRvcDog NTBweDt9CiAgICAjcmVkIHsgcG9zaXRpb246IHJlbGF0aXZlOyB0b3A6IDI1cHg7IGJhY2tncm91 bmQ6IHJlZDsgZGlzcGxheTogYmxvY2s7ICB3aWR0aDogMTAwcHg7IGhlaWdodDogMTAwcHg7fQog IDwvc3R5bGU+CiA8L2hlYWQ+CiA8Ym9keT4KICAgICA8c3BhbiBpZD0icGFyZW50Ij4KICAgICAg IDxzcGFuIGlkPSJyZWQiPjwvc3Bhbj4KICAgICA8L3NwYW4+CiA8L2JvZHk+CjwvaHRtbD4= 109192 2011-09-29 12:59:53 -0700 2011-09-29 12:59:53 -0700 Easier to understand reduction bug53140.html text/html 780 robert PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEvL0VOIiAiaHR0cDov L3d3dy53My5vcmcvVFIvaHRtbDQvc3RyaWN0LmR0ZCI+CjxodG1sPgogPGhlYWQ+CiAgPHN0eWxl IHR5cGU9InRleHQvY3NzIj4KICAgICNncmVlbiB7IHBvc2l0aW9uOiBhYnNvbHV0ZTsgdG9wOiA3 NXB4OyBiYWNrZ3JvdW5kOiBncmVlbjsgd2lkdGg6IDEwMHB4OyBoZWlnaHQ6IDEwMHB4O30KICA8 L3N0eWxlPgogPC9oZWFkPgogPGJvZHk+CiAgICBJZiB0aGVyZSBpcyBubyByZWQsIHRoZSByZWQg cmVscG9zIGJsb2NrIGlzIGNhbGN1bGF0aW5nIGl0cyBvZmZzZXQgZnJvbSBpdHMgcmVscG9zIGlu bGluZSBwYXJlbnQuCiAgICA8ZGl2IGlkPSJ0b3AiIHN0eWxlPSJwb3NpdGlvbjogYWJzb2x1dGU7 IHRvcDogMDsiPgogICAgIDxzcGFuIGlkPSJwYXJlbnQiIHN0eWxlPSJwb3NpdGlvbjogcmVsYXRp dmU7IHRvcDogNTBweCI+CiAgICAgICAgPCEtLSBDU1MgVGVzdCBzdWl0ZSBleHBlY3RzIHRoaXMg YmxvY2sgdG8gb2Zmc2V0IDI1cHggZnJvbSB0aGUgcmVsYXRpdmUgaW5saW5lIGFib3ZlLCBnaXZp bmcgYSB0b3RhbCBvZmZzZXQgb2YgNzVweC0tPgogICAgICAgPGRpdiBpZD0icmVkIiBzdHlsZT0i cG9zaXRpb246IHJlbGF0aXZlOyB0b3A6IDI1cHg7IGJhY2tncm91bmQ6IHJlZDsgd2lkdGg6IDEw MHB4OyBoZWlnaHQ6IDEwMHB4OyI+PC9kaXY+IAogICAgIDwvc3Bhbj4KICAgIDwvZGl2PgogICAg PGRpdiBpZD0iZ3JlZW4iPjwvZGl2PgogPC9ib2R5Pgo8L2h0bWw+