[css-tables] Background rendering model

[FremyCompany]

Should col/colgroup/row/rowgroup backgrounds be rendered on the cells individually (with proper position/size considerations) or on the col/colgroup/tr/tbody elements and clipped to the position of visible cells (they can possibly extend beyond the borderbox of the row/col which means this would require a lot of special logic)

Currently the spec renders backgrounds and borders on the cells, which enable to unify separated and collapsed modes, and explains cleanly the expected rendering.

It does not allow to render the background of the row under an hidden cell, though.

[tabatkins]

@atotic How do we render our table backgrounds? I know you worked on this recently. ^_^

[FremyCompany]

For completeness, here is the original comment that prompted this issue:

---

There should be a way to show the <tr> background by using visibility:hidden [on the cell].

I am not so sure how that is actually useful. The point is that we are going to need to sacrifice some things with tables because they cannot possibly work like the rest of css. What we are going to sacrifice is the question. I would argue having the backgrounds of the tr rendered on the cells instead of being clipped to the cells makes more sense because it then "sticks" to the cell, for instance if you transform it:

https://wptest.center/#/ihhvr4

---

Also for some fun (also try to uncollapse the row):
https://wptest.center/#/kniad8

[atotic]

Definitions:
CCTT = col/colgroup/tr/tbody
Large cell = cell with colspan/rowspan > 1

Chrome renders CCTT backgrounds badly. It fails in many cases, and will evolve a lot. FF is the golden standard of table rendering. I've attached my homemade torture test case.span.txt

Chrome code renders CCTT backgrounds and borders on cells. Interesting things I've learned while wresting with the code:

a) frame rect of a CCTT background image is not CCTT frame rect. It is a rectangle defined by first and last cell inside CCTT. But not exactly: if a cell is a large cell, we pretend it is a regular cell for frame rect computation.

b) a large cell might cause normally non-repeating background (background-size: 100%;) to repeat.

c) in actual implemenation, borders of border-collapse:collapse tables should be painted at the table level. Single border can span multiple cells. If you are painting on cell level you have to paint the same border on multiple cells, and clip, which is inefficient. Painting borders on cells can work in a spec because you do not care about efficiency.

d) deciding which border wins in border intersections of collapsed cells in different writing modes is tricky. My torture test case is attached.
intersections.txt

The "render background of row under hidden cell" question is interesting.FF renders it, Chrome does not. From the implementation point of view, two are equivalent, it is all one big special case. But, from a webdev point of view, hiding a cell in the middle of my table with a red background should not leave a white rectangle in the middle. Here I lean towards: hidden cells should expose CCTT backgrounds.

If we answer yes to the question above, then backgrounds should be painted not by cells, but by TTCC,

Points a) and b) above make painting of TTCC backgrounds unlike any other backgrounds painted in CSS.

[atotic]

I did not think about transformed cells.

I am worried about border painting for collapsed cells. If borders are painted by cells, painting a single border will require multiple drawing calls. Drawing single image in multiple parts can result in subpixel leaks when rotated (ex: http://crbug.com/143601 ).

There are no clean answers here. As a web developers, I'd want:

• hidden cells show backgrounds underneath. This enables decorative backgrounds and hidden cells to coexist.
• transformed cells "carry" their borders and backgrounds with them. The table renders as if cells were hidden, the cells themselves get rendered separately.