Re: [csswg-drafts] [css-tables] visibility: collapse

One more option surfaced at TPAC
E: if overflow:visible then re-layout, else clip
and I want to introduce
F: Hide any cells that span the collapsed track

The consensus at TPAC seemed to be that A was bad, and B/C weren't 
discussed. E gives authors the option of A or D. But D, a re-layout, 
is specifically what visibility:collapse was introduced to prevent, 
right? And if A is bad, why do we want to offer it as an option? So my
 initial take is to vote against E.

I don't like C because it could be a point of confusion/frustration 
for authors: visibility:collapse works for some tracks and doesn't 
work for others and it would take some investigation that spanned 
cells are the culprit.

I'm not necessarily advocating for F, but want to discuss it. Authors 
would immediately understand the effect that collapsing has on spanned
 cells, while with the other potential behaviors may not be so obvious
 (i.e. Edge and FF do the same thing with 
https://jsfiddle.net/dgrogan/9emqs2zh/5/)

I don't want to drop the feature. It's chrome's most requested table 
feature; developers want it.

I'm probably overlooking some important constraints, hopefully we can 
have an off-the record convo about all this (off-the-record just so I 
don't look stupid).

Asides:

I don't see that Safari has implemented this at all (tested r210282 
from a few days ago). They seem to treat visibility:collapse the same 
as Chrome. And their bug for it is still open 
https://bugs.webkit.org/show_bug.cgi?id=8735 Am I missing something?

Looks like Edge (38.14393.0.0) has a bug when a row is collapsed and 
uncollapsed: the clipped text and border are not redrawn:
https://jsfiddle.net/dgrogan/9emqs2zh/

-- 
GitHub Notification of comment by davidsgrogan
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/478#issuecomment-271364877 
using your GitHub account

Received on Monday, 9 January 2017 18:31:31 UTC