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

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

> [Applying] "row collapse" to cells with visibility: hidden dose 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 applied element.

Yes. 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] 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).

GitHub Notification of comment by FremyCompany
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 26 July 2017 17:37:35 UTC