STR: 1. Load attached testcase. ACTUAL RESULTS: Orange abspos element stomps on top of the table border. EXPECTED RESULTS: Orange abspos element should be just inside table border (since abspos positioning area is the padding-box, which is inside the border). At least, this is what would happen if the container were a block. Chrome 54 gives EXPECTED RESULTS. Firefox Nightly (51) gives ACTUAL RESULTS. So does Edge 14. (Not sure who's right -- but apparently Yahoo Japan slightly depends on the Chrome behavior for the correct positioning of its "search" button in its auction search box as noted at https://github.com/webcompat/web-bugs/issues/1380#issuecomment-245190208 )
Huh, I think the relevant spec-text here is: > 4. If the element has 'position: absolute', the containing block is established > by the nearest ancestor with a 'position' of 'absolute', 'relative' or 'fixed', > in the following way: > 1. In the case that the ancestor is an inline element, [...] > 2. Otherwise, the containing block is formed by the padding edge of the ancestor. https://www.w3.org/TR/CSS22/visudet.html#containing-block-details That leads me to believe that the table's padding-box (inside of the border-box) should form the containing block here. It's a bit odd that Edge matches us, though. I wonder if there's some other table special-case defined elsewhere. dbaron, do you know what might be going on here? Perhaps we're treating the nsTableWrapperFrame as our containing block? (and is there spec support for that?)
Aha! There is some spec text about table wrapper boxes here: > The table wrapper box establishes a block formatting context, > and the table box establishes a table formatting context. [...] > The width of the table wrapper box is the border-edge width of > the table box inside it. > The computed values of properties 'position', [...] are used on the table wrapper box and not the table box; https://www.w3.org/TR/CSS22/tables.html#model This sounds like it's saying our behavior is correct -- the table wrapper box is indeed supposed to become the relatively-positioned box (the abspos containing block for descendants in the testcase), and it's the size of the table's border-box -- i.e. it's positioned outside the table's border. So abspos children at 0,0 should indeed stomp on the table's border.
I guess I'll close this as INVALID and file a Chrome bug, then.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=644806 on Chrome/Blink.
And https://bugs.webkit.org/show_bug.cgi?id=161700 on Safari/WebKit.
See Also: → https://bugs.webkit.org/show_bug.cgi?id=161700
You need to log in before you can comment on or make changes to this bug.