Intent to Ship: visibility:collapse for table rows

104 views
Skip to first unread message

Joy Yu

unread,
Aug 7, 2017, 6:36:49 PM8/7/17
to blink-dev

Contact emails

joy...@google.com, dgr...@chromium.org


Spec

https://drafts.csswg.org/css-tables-3/#visible-track

https://www.w3.org/TR/CSS2/tables.html#dynamic-effects


There is no TAG review because they haven't reviewed css-tables-3 yet. Is a TAG review needed on a feature that was first specified in CSS2 in 1998? 


Summary

Visibility:collapse is supposed to hide table rows while preserving their contribution to column widths. Right now Blink treats visibility:collapse as visibility:hidden, which merely skips painting the rows, leaving blank space instead of allowing the space to be used for other content.


Link to “Intent to Implement” blink-dev discussion

Link here


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Demo link

Basic example


Interoperability and Compatibility Risk

Firefox: Shipped Edge: Shipped Safari: Mixed public signals (patch posted in 2007 but no movement since) Web developers: Positive

Edge and Firefox are interoperable for the common case but differ when rowspan cells are affected. See https://bugs.chromium.org/p/chromium/issues/detail?id=174167#c35 for examples. Edge implements the CSS2.1 behavior, which is what we have done as well.

Some sites may be using visibility:collapse when they really want visibility:hidden, relying on the fact that Blink and WebKit render them the same. But these sites would render differently in Edge and FF, so this would mostly affect WebKit/Blink-only sites. If the new behavior is unwanted, the fix is simple: change "visibility:collapse" to "visibility:hidden", which is what they meant from the start.


Is this feature fully tested by web-platform-tests?

Tests here.


OWP launch tracking bug

None yet - the technical bug is https://crbug.com/174167


Entry on the feature dashboard

Link here.

PhistucK

unread,
Aug 8, 2017, 2:47:30 AM8/8/17
to Joy Yu, blink-dev
I am probably in the minority here, but I think it would be better to make sure everything is accurately and precisely specified (and has consensus) before shipping this. In the difference example link, it says "look bad" in both of the cases, so perhaps this should be discussed in the working group first in order to close this loop.
If you could spend some time trying to spark this discussion and maybe champion a decision acceptable by everyone, that would be great.

It is worrisome that WebKit has mixed signals... Hopefully they would accept your contribution and be done with it.


PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALkuPp%3DFbhbLqtzpjsWLm_gvA5pFXKDjXGau-_HUDfmOkQPRwA%40mail.gmail.com.

Rick Byers

unread,
Aug 8, 2017, 9:08:45 AM8/8/17
to Joy Yu, blink-dev
LGTM1

Thank you for improving interop and spec conformance!

On Mon, Aug 7, 2017 at 6:36 PM, 'Joy Yu' via blink-dev <blin...@chromium.org> wrote:

Contact emails

joy...@google.com, dgr...@chromium.org


Spec

https://drafts.csswg.org/css-tables-3/#visible-track

https://www.w3.org/TR/CSS2/tables.html#dynamic-effects


There is no TAG review because they haven't reviewed css-tables-3 yet. Is a TAG review needed on a feature that was first specified in CSS2 in 1998? 


Nah, this is small (arguably a bug-fix since we already support the API, just badly) and it's already shipped in two browsers so any time for API review has long passed ;-)

Summary

Visibility:collapse is supposed to hide table rows while preserving their contribution to column widths. Right now Blink treats visibility:collapse as visibility:hidden, which merely skips painting the rows, leaving blank space instead of allowing the space to be used for other content.


Link to “Intent to Implement” blink-dev discussion

Link here


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Demo link

Basic example


Interoperability and Compatibility Risk

Firefox: Shipped Edge: Shipped Safari: Mixed public signals (patch posted in 2007 but no movement since) Web developers: Positive

Edge and Firefox are interoperable for the common case but differ when rowspan cells are affected. See https://bugs.chromium.org/p/chromium/issues/detail?id=174167#c35 for examples. Edge implements the CSS2.1 behavior, which is what we have done as well.

Some sites may be using visibility:collapse when they really want visibility:hidden, relying on the fact that Blink and WebKit render them the same. But these sites would render differently in Edge and FF, so this would mostly affect WebKit/Blink-only sites. If the new behavior is unwanted, the fix is simple: change "visibility:collapse" to "visibility:hidden", which is what they meant from the start.


Is this feature fully tested by web-platform-tests?

Tests here.


Thanks for adding these!

It looks like Firefox passes almost all of them and Edge passes most.   Have you been in touch with anyone at Mozilla about the couple failures they have (eg. filed a bug for them)?



OWP launch tracking bug

None yet - the technical bug is https://crbug.com/174167


Entry on the feature dashboard

Link here.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Rick Byers

unread,
Aug 8, 2017, 9:10:59 AM8/8/17
to PhistucK, Joy Yu, blink-dev
On Tue, Aug 8, 2017 at 2:46 AM, PhistucK <phis...@gmail.com> wrote:
I am probably in the minority here, but I think it would be better to make sure everything is accurately and precisely specified (and has consensus) before shipping this. In the difference example link, it says "look bad" in both of the cases, so perhaps this should be discussed in the working group first in order to close this loop.

Sorry what example is this?
 
If you could spend some time trying to spark this discussion and maybe champion a decision acceptable by everyone, that would be great.

It is worrisome that WebKit has mixed signals... Hopefully they would accept your contribution and be done with it.

 I wouldn't call this mixed signals - I see no active opposition, just the usual lack of response.  It's fair to assume it's low priority (like so many WebKit interop issues).  That Joy is offering to land a patch in WebKit as well is awesome, but absolutely not required to ship in blink :-)

Phist

PhistucK

unread,
Aug 8, 2017, 9:31:53 AM8/8/17
to Rick Byers, Joy Yu, blink-dev
Quote -
"It's unclear what the behavior should be when a spanned cell crosses a collapsed row. Edge clips the content, but it looks bad. Firefox lets the content overflow (see the attached screenshot), which also looks bad."

I might be nitpicking on the "looks back" parts, but I really prefer solidifying the edge cases with a consensus.


PhistucK

Rick Byers

unread,
Aug 8, 2017, 1:36:37 PM8/8/17
to PhistucK, Joy Yu, blink-dev, David Grogan
On Tue, Aug 8, 2017 at 9:31 AM, PhistucK <phis...@gmail.com> wrote:
Quote -
"It's unclear what the behavior should be when a spanned cell crosses a collapsed row. Edge clips the content, but it looks bad. Firefox lets the content overflow (see the attached screenshot), which also looks bad."

Thanks. 

I might be nitpicking on the "looks back" parts, but I really prefer solidifying the edge cases with a consensus.

Yes that's definitely what we should aim for.  In this case Edge and Firefox already disagree I personally don't think it's worth blocking shipping in Chrome on this.  But deviations like this do contribute to "interop risk" and so are totally in scope for intent-to-ship discussions - thanks for bringing it up!

That said, if I'm interpreting the discussion correctly, this has now been resolved in favor of Edge's behavior and that's indeed what Chrome is now doing.  Joy/David, do you know if that's covered by one of your tests that are failing in Firefox?  Is there a Firefox bug tracking their failures, and if not would you mind filing one?

David Grogan

unread,
Aug 8, 2017, 6:25:25 PM8/8/17
to Rick Byers, PhistucK, Joy Yu, blink-dev
The CSS WG resolved on the Edge behavior last week. FF has a bug to change their clipping behavior (covered by http://wpt.fyi/css/css-tables-3/visibility-collapse-rowspan-005.html)

The other tests that wpt.fyi reports failing on FF pass locally, on linux with FF 57. (Commented on a bug about diagnosing this.)


Mike West

unread,
Aug 9, 2017, 5:53:20 AM8/9/17
to David Grogan, Rick Byers, PhistucK, Joy Yu, blink-dev

Dimitri Glazkov

unread,
Aug 9, 2017, 11:52:52 AM8/9/17
to Mike West, David Grogan, Rick Byers, PhistucK, Joy Yu, blink-dev
LGTM3

LGTM2.


-mike


PhistucK

Phist
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_LGtJC0H5s4_p-H4dAhWDPtpmgexhZ7WFoA6QgOx9ka0w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Rick Byers

unread,
Aug 9, 2017, 6:37:31 PM8/9/17
to David Grogan, PhistucK, Joy Yu, blink-dev
Sounds perfect, thanks for the follow-up David!
Reply all
Reply to author
Forward
0 new messages