[css-tables] should 'opacity' be hoisted from the table box to its wrapper box

[dbaron]

CSS 2.1 specifies, in the rules on tables, a list of properties that, when specified on a table, apply to the table wrapper box rather than the table box.

css-color-3 introduces the opacity property.

I haven't tested carefully yet, but https://bugzilla.mozilla.org/show_bug.cgi?id=1286803 suggests that some but not all browsers include 'opacity' in the list of properties to be hoisted to the table wrapper box. Doing so produces the expected results, in that the caption (inside the table) gets included in the effect of 'opacity'.

I suspect specifying this is the right thing to do, but further testing (e.g., making sure that the implementations that apply the opacity to the caption are actually doing correct group opacity when the table and caption overlap) is probably warranted first.

[svgeesus]

Agree that testing that group opacity is applied (rather than individual opacity on caption and table) would be helpful. Also that hoisting is probably the right thing.

[fantasai]

Filters should also be hoisted up. I'm unsure about masking, though.

[dbaron]

I think masking will cause confusion either way (on a table, when a caption is present). With hoisting, the position/size of the mask will be unexpected, and without hoisting, the caption won't be included. I'd lean weakly towards not hoisting, but I don't feel strongly.

[smfr]

Maybe all of these grouping properties should hoist:
https://drafts.csswg.org/css-transforms/#grouping-property-values

[dbaron]

In today's teleconference the WG resolved to hoist opacity, and to discuss the rest of the list of properties at TPAC.

[FremyCompany]

Just a self-reminder that the class of issues I wanted to discuss is a bit wider than what we resolved two weeks ago, as a result of my attempt to make TBODY/TR and COLGROUP/COL more alike and sane: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8128253/

I think we want to preserve the non-Edge behavior of allowing transforms&friends on table-track and table-track-grouping boxes, and hoist these features directly onto the cells. The current behavior (having them on an actual TR wrapper) is really weird due to where and how backgrounds and borders are currently drawn in most browsers, and I would like to get rid of that non-sense. Still, at the same time, I don't think Edge's behavior of just applying display:contents on those elements is totally web-compatible, hence the hoisting proposal.

We should discuss this further at TPAC when @gregwhitworth and myself will present the CSS Tables spec.

[FremyCompany]

Resolved that we do, except for 'overflow' which currently doesn't work (at least in most cases) and that we might want to drop altogether.

[dbaron]

In particular, I believe we resolved on the list @smfr referenced above, which is currently: opacity, filter, clip, clip-path, isolation, mask-image, mask-border-source, mix-blend-mode, transform, perspective.

However, there are some other properties that go along with those, so I believe we should also be including mask-* (since hoisting mask-image and mask-border-source without the properties that go with them is silly), and also transform-origin (which goes with transform) and perspective-origin (which goes with perspective), and I think also backface-visibility (which goes with the transform stuff, I think).

Of these, Gecko currently hoists transform, transform-origin, backface-visibility, and clip

[FremyCompany]

I just checked and Chrome hoists 'overflow:hidden' too. You can see this by creating a positioned element crossing the caption, like here: https://jsfiddle.net/t54tjzw1/1/

I therefore went ahead and added it to the list, though that is of course pending a resolution. I propose we make the values scroll and auto behave as visible as this seems interoperable. I also propose to normatively reference this list so that they stay in sync (and maybe add a note at the bottom of this list in the transforms spec noting this list is referenced in css-tables-3)?

I still anticipate the easiest way to solve this class of problem is to put things on their head and have the table-wrapper-box use all properties by default and have the "table-grid-box" be the one that gets exceptionally the "background", "border" as well as a few other properties from its parent, but we will leave this discussion for later. Let's get the behavior defined, then we can debate whether there are better ways to spec it.

[dbaron]

The list of properties that need to stay on the primary box is pretty long: anything to do with sizing (min/max/regular width/height, padding, margin), borders, backgrounds, animations, transitions, and probably also hit testing and ability to focus/select/etc., generated content (i.e., location of pseudo-elements).

(Hoisting doesn't make a difference for inherited properties, since the table wrapper box inherits them from the table -- although that should be more explicitly specified.)

But there are some flex and grid properties that should also be hoisted.

[svgeesus]

It wasn't clear to me in which spec this hoisting should be described. Per-property across a range of specs, or in the table spec? My preference would be the latter.
I agree this needs a bunch of careful tests with tables and opacity.

[svgeesus]

If this would be a change to the color spec, it would go in level 4.

[svgeesus]

@FremyCompany wrote

I still anticipate the easiest way to solve this class of problem is to put things on their head and have the table-wrapper-box use all properties by default and have the "table-grid-box" be the one that gets exceptionally the "background", "border" as well as a few other properties from its parent, but we will leave this discussion for later.

That sounds like a better approach, so removing the color-4 tag.

[FremyCompany]

@svgeesus Sounds like the right call!