[css-tables] Painted extent of table cell background when border collapsing is in effect #9643
Description
We've seen a number of reports of interop issues that essentially boil down to a question of how table cell backgrounds are sized in tables using border-collapse:collapse.
In CSS2 it was explicitly noted that
CSS 2 does not define where the edge of a background on a table element lies.
(It wasn't immediately apparent to me whether the current draft of CSS Tables 3 attempts to addresses this better; but also, I noted the stern "not ready" warning across the front of that draft.)
Here's a simple testcase: https://drafts.csswg.org/css2/#collapsing-borders.
Some observations:
(1) The cell backgrounds (click the checkbox to give them a color) extend "under" the borders, which in this example are semi-transparent. All of Gecko, Blink and WebKit currently agree on this (although it strikes me as a bit unexpected; we'll come back to this).
(2) Clicking the second checkbox will set position: sticky on cell 2. This will cause the cell to form a new stacking context (as required by CSS Positioning. That means that its background will now be in front of the borders, as they are attached to the table as a whole and not the individual cells. (All 3 engines agree on this, as we'll confirm in a moment.)
However, there's a major difference in rendering between Gecko and the other two. In Gecko, the cell background is unchanged by setting position: sticky, it just moves in front of the borders, and hence overpaints half their width. In Blink and WebKit, on the other hand, the cell background is reduced in size such that it fits inside the collapsed borders, and does not overpaint them. I haven't run across spec text that says this should happen.
(3) The third checkbox applies position: relative to cell 3. Again, Gecko keeps the cell background at its original size, whereas Blink and WebKit shrink it to the size of the interior of the cell borders. This cell also has top and left values set, so that with relative positioning, it gets offset and thus it becomes clear that its background is now rendering (in all 3 browsers) in front of the borders.
So my primary question here is whether Blink and WebKit are correct to restrict the painted extent of the cell background to the interior area in these cases.
We've had a number of bugs filed against Gecko over the years as a result of cell backgrounds overpainting collapsed borders, where Blink and WebKit would reduce the background size and so the borders remain fully visible. I'm proposing to patch Gecko so as to behave similarly to the other browsers in this regard, but it also seems to me that the spec should make it clear what is expected.
A second question is whether the painting of the background should actually be restricted to the interior of the collapsed borders in all cases, not only when the cell forms a new stacking context. In other words, are current browsers wrong to paint the cell background underneath the inner half of the borders, as seen in cell 1? It seems to me quite surprising that changing the position property of the cell "magically" changes the painted size of its background. In most cases (when borders are opaque) this is invisible, but with (partially) transparent borders it becomes evident, and seems wrong to me. Does the CSS WG (or the Tables spec) have an opinion on this?