[csswg-drafts] [css-tables] table root as containing block for abs-pos (#6021)

jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-tables] table root as containing block for abs-pos ==
Browsers currently disagree regarding the containing block used to position an absolutely-positioned element when the containing block is generated by a table wrapper and there are borders present.

I've put a simple example at https://codepen.io/jfkthame/pen/GRNEbVq?editors=1100.

The current draft text at https://drafts.csswg.org/css-tables-3/#abspos says that:

> If an absolutely positioned element’s containing block is generated by a table-wrapper box, the containing block corresponds to the area around which the table margins are applied, ***including the area where the table border is drawn*** and the margin area of any table-caption.

(my emphasis), though we should note that the entire css-tables-3 spec is marked as being "not ready for implementation".

This matches the behavior currently implemented in Firefox, and means that the final square in the above example "works" as intended (displays solid green), while the penultimate one is broken.

However, in both Chrome and Safari, that final square renders incorrectly, while the preceding one "works".

That preceding test element is styled on the assumption that the containing block generated by the table-wrapper box does *not* include the area where the border is drawn, just as if the box were generated by `display:block`.

Offhand it seems slightly surprising that the table wrapper should be an exception to the usual case where borders are *outside* the abs-pos containing block that is generated, but perhaps there was good reason for this? (I don't know the history of the Firefox implementation or the draft spec text here.)

Anyhow, one way or another I'd like to see this discrepancy resolved. We've had a bug report filed against Firefox because the reporter expected the `display: table` element to behave similarly to `display: block` in terms of the abs-pos containing block generated; the reporter is clearly assuming the Chrome/Safari behavior is correct.

Should we plan to change Gecko's behavior here to align with Blink & Webkit, and expect the css-tables-3 text to change accordingly? Or does the current draft reflect behavior that we specifically want to maintain, and Blink & Webkit should be asked to align with Gecko here?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6021 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 19 February 2021 12:33:08 UTC