[css-tables] table root as containing block for abs-pos

[jfkthame]

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?

[faceless2]

We follow Gecko's behaviour too. I think this derives from this text in CSS2:

The computed values of properties 'position', 'float', 'margin-*', 'top', 'right', 'bottom', and 'left' on the table element are used on the table wrapper box and not the table box;

So the table wrapper becomes the positioned element. Correct or not, it's been that way for a long time.

[jfkthame]

Thanks, Mike. In that case I hope some webkit & blink people will chime in with their take on this.

Here's an additional example: https://codepen.io/jfkthame/pen/xxRLKyP

I think this one shows a case where the webkit/blink behavior really doesn't make any sense: the abs-pos box containing "X" ends up inset from the outer edge of the caption's border by the thickness of the table's border. (Whereas in gecko the abs-pos box stays at the outer corner of the caption's border.)

[jfkthame]

Further investigation shows there's a longstanding bug report about this behavior in blink (and webkit): https://bugs.chromium.org/p/chromium/issues/detail?id=644806. E.g. comments 9 and 12 there appear to agree that their behavior is wrong.