[css-tables-3] Can we simplify empty-cells:hide?

[FremyCompany]

1. The definition of an empty cell is not trivial. Could we simplify to just matching :empy like Chrome seems to be doing?
2. The spec mentions that rows that have only empty cells should collapse. I don't see this behavior implemented anywhere. I went ahead and dropped it from the spec. Should we resolve on this and update CSS 2 to match?
3. If we decide to do both 1 and 2, can we just say that when empty-cells:hide applies, cells matching :empty are displayed like if they had visibility:hidden applied to them?

[fantasai]

I'm 100% sure that cells containing only collapsible white space need to be considered empty. This is especially important because the </td> tag is optional. It's possible we can modify :empty to follow that definition, and we might want to do that, but certainly as things stand you can't treat these cells as hidden when :empty.

[FremyCompany]

@fantasai That makes sense to me. When I wrote :empty I meant "does not contain any box at layout time", not "any node at dom time" (which the selector analogy incorrectly implied, sorry).

One can indeed easily confirm that collapsed space does not count while uncollapsed space does not:
https://jsfiddle.net/p2aj9ju2/

The difference lies in the way out-of-flow elements are handled:
https://jsfiddle.net/p2aj9ju2/2/

[cathiechen]

Confused about cells with visibility: hidden. empty-cells works when cells with visibility: hidden.

I guess empty-cells controls the background of layers between <table> and <td>, visibility: hidden controls only the applied element.

Cells with visibility: hidden could have visible children, e.g.
<td style="visibility: hidden;"><div style="visibility: visible;">content</div></td>
This cell actually has visible content.

And "row collapse" to cells with visibility: hidden dose not seem reasonable too.

[FremyCompany]

@cathiechen I am not sure I understood all your points correctly but

[Applying] "row collapse" to cells with visibility: hidden does not seem reasonable.

I agree. The fact is though that no browser does that with empty-cells either, it seems like we just need a resolution to remove this text from CSS 2.1 and move on. If we can agree on this, and I am confident we will, then empty-cells will only control visibility not layout.

I guess empty-cells controls the background of layers between <table> and <td>, while visibility: hidden controls only the [background] applied on [the <td>] element.

The spec text from css 2.1 is that "In the separated borders model, if the value of their 'empty-cells' property is 'hide' these "empty" cells are transparent through the cell, row, row group, column and column group backgrounds, letting the table background show through".

But, no, visiblity:hidden should also hide the backgrounds defined on the <tr> element btw, because it is actually rendered on the cell itself not on the <tr>. You can verify this is true in both Edge and Chrome. It looks like this isn't true in Firefox but this behavior is even more difficult to spec because now the table row needs to clip its background to the border box of the cells it contain and I am 100% positive I don't want to spec this behavior.

[But] cells with visibility: hidden could have visible children, e.g.
<td style="visibility: hidden;"><div style="visibility: visible;">content</div></td>
This cell actually has visible content.

Yes. In browsers that support the CSS 2.1 text, cells affected by empty-cells:hide can also have visible content (position:absolute elements for instance) though the cell itself will be hidden. The property actually behaves like if the cells had a special visibility:hidden value set to them, that gets inherited as visible by their element/pseudo-element children (if any).

The reason I am proposing (3) is that if we accept proposal (1) then there will be no content inside the cell that could be shown anyway, so the behavior will be strictly identical to visibility:hidden and will not require any particular text explaining its behavior.

If we decide that Chrome should match Edge and Firefox instead and hide cell backgrounds for cells that only contain absolutely positioned content, then I agree we need to keep some of the current text and cannot apply (3). Resolving positively on (1) and (2) is required in order to get to (3).

[cathiechen]

But, no, visiblity:hidden should also hide the backgrounds defined on the element btw, because it is actually rendered on the cell itself not on the . You can verify this is true in both Edge and Chrome. It looks like this isn't true in Firefox but this behavior is even more difficult to spec because now the table row needs to clip its background to the border box of the cells it contain and I am 100% positive I don't want to spec this behavior.

@FremyCompany I think Firefox's behavior is more reasonable. e.g.
Case 1: "empty-cells:hidden" + <td style="visibility:hidden"> ==> show <table> background
Case 2: "empty-cells:show" + <td style="visibility:hidden"> ==> show <tr> background (Firefox) or <table> background (Chrome, Safari and Edge)?

We are agreed that "case 1" should show table background. As to "case 2", I think it should show <tr> background. For these reasons:

1. As empty-cells:show is a default behavior, it shouldn't influence other properties. So the result should be decided by visibility:hidden, and <tr> background should be shown.
2. There should be a way to show <tr> background by using visibility:hidden.

This behavior should be confirmed. From the perspective of visibility:hidden, if it's decided "case 2" should show <table> background, then empty-cells seems have no power when meets visibility:hidden. So I think it could be simplified. On the contrary, I think we should remain empty-cells.

[FremyCompany]

There should be a way to show background by using visibility:hidden.

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

But that, really, is another question entirely. You are right it would be necessary to resolve this question first. If we want to render on the TR/TBODY/COL/COLGROUP and clip based on the table layout instead of letting each cell draw things for themselves, then we cannot merge empty-cells:hidden and visiblity:hidden either.

[FremyCompany]

Depends on #1657