should it be possible for an element with contain:paint to be part of a transform-style:preserve-3d scene?

[dbaron]

Right now the specs for contain:paint and for transform-style allow an element with contain: paint to be part of a 3D scene. If such an element both has transform-style: preserve-3d and has a parent that does, then this means that its children (or further descendants, if the children have transform-style: preserve-3d) are rendered as part of its parent's (or further ancestor's, if the ancestor chain has transform-style: preserve-3d further up) 3D scene.

While the intended guarantees of contain: paint aren't clearly defined, it seems a bit nonintuitive to me that it would allow children to escape the container in this way.

What is the desired behavior here?

[frivoal]

I'm not sure. Given that paint-contained element cannot have visible overflow, is there really an issue?
If I understand correctly, their content would get positioned into the ancestor's 3D scene, but whether they get painted or not is still depends on whether they overflow the bounds of the containing element, as it would with any other ancestor with overflow:clip. (in the case of non-clip, non-visible overflow, the problem doesn't arise, as the other values cause flattening).

If this is a misunderstanding, and elements that are part of a 3D scene do not get clipped at the boundaries of an overflow:clip element, then I suspect the correct answer is to add contain: paint to the list of property/value pairs that force the element to have a used style of flat for preserve-3d in https://drafts.csswg.org/css-transforms-2/#grouping-property-values

[chrishtr]

Contain:paint's clip is the same as an overflow:clip. I don't remember why that restriction is there in the transforms spec, can we just make overflow:clip a grouping property?

[tabatkins]

I agree that contain:paint should be a grouping property, yes.

And I think it makes sense for overflow:clip to be one too; it's not clear to me why it would make sense, or what it would mean, for a clipped-overflow element's descendants to be able to escape it in 3d.

[css-meeting-bot]

The CSS Working Group just discussed should it be possible for an element with contain:paint to be part of a transform-style:preserve-3d scene?, and agreed to the following:

• RESOLVED: add contain:paint to list of grouping properties

The full IRC log of that discussion

<dael> Topic: should it be possible for an element with contain:paint to be part of a transform-style:preserve-3d scene?
<dael> github: https://github.com//issues/6202
<dael> TabAtkins: The summary is when you have a preserve3d transform nothing prevents a contain:paint participate in the 3d scene.
<dael> TabAtkins: A bunch of properties restricted to force it to become flat so children are container
<dael> TabAtkins: contain:paint should work the same
<smfr> overflow does NOT create a graphical group
<dael> TabAtkins: Spec also allows overflow-clip to have children leave element entirely and florian pointed out that doesn't make sense.
<smfr> q+
<dael> TabAtkins: If we're having overflow:contain-paint to cause flattening we should have them both
<dael> TabAtkins: Prop: add contain-paint to list of grouping properties that force it to be flat. Remove clip value form exceptions so it also causes it to be flat
<dael> smfr: I think this is right thing. I think contain-paint causes stacking but should flatten
<dael> smfr: I think TabAtkins said non-visbile overflow creates stacking?
<Rossen_> ack smfr
<dael> TabAtkins: Overflow-clip is on list of values that don't cause flattening. Feels weird. I think it should
<chrishtr> agree that clip and contain:paint should cause flattenign
<dael> smfr: That's fine. I agree with proposal
<TabAtkins> s/overflow-clip/overflow:clip/
<dael> dbaron[m]: I agree as well
<dael> Rossen_: Other feedback or objections?
<dael> smfr: Prop to make coverflow:clip a grouping property. Impl it creates stacking context?
<dael> florian: DOn't think so
<dael> smfr: Think it does
<dael> dbaron[m]: We do have that grouping prop create stacking context. That said, I wrote a test a few weeks ago to see what rbowsers made group. Tested with transform flattening and mixed blend and got entirely different results in all browsers.
<dael> dbaron[m]: Given that I think we don't have a good sense of grouping
<dael> smfr: Testing with opacity or filters might have given more consistent
<dael> smfr: I don't want to separate grouping from stacking context. Would create complexity
<dael> florian: I don't think the grouping are defined to create stacking
<dael> dbaron[m]: Don't have a spec for this. I did have understanding that the set of things grouping is subset of things that create stacking
<dael> TabAtkins: Happy to remove overflow:clip part and just do contain-paint
<dbaron[m]> the test I'm talking about was https://dbaron.org/css/test/2018/stacking-context-z-order
<dael> smfr: contain-paint can imply overflow:clip. Would love overflow properties that create stacking, but that ship has sailed
<dael> Rossen_: TabAtkins just resolve on contain:paint and leave overflow:clip for now?
<dael> TabAtkins: Yes
<dael> Rossen_: That's the proposal. thoughts or objections?
<dael> florian: Thought; maybe misunderstanding. Seems it's not necessary for overflow:clip to flatten a 3d transform b/c can position in 3d model. If when it's time to paint the projection is outside area you paint you clip
<dael> smfr: Please don't make clipping a thing we nee din 3d scenes
<smfr> q+
<dael> Rossen_: Great convo that should happen when additional investigation of overflow:clip takes place
<dael> smfr: If we resolve on this do we need to resolve on if will-change contains side effects. From dbaron[m] chart it does nto have stacking.
<dael> TabAtkins: Can you open as separate issue?
<dael> smfr: Yes
<dael> Rossen_: not hearing objection sot contain:paint
<dbaron[m]> I think will-change's definition is pretty clear about what's �supposed� to happen...
<dael> RESOLVED: add contain:paint to list of grouping properties
<dael> Rossen_: Anything else on this?

[smfr]

Filed #6373 on will-change: contain and stacking context.

[dbaron]

To follow up on this mornings discussion -- I noticed that the compositing spec says (for HTML but not SVG):

Everything in CSS that creates a stacking context must be considered an ‘isolated’ group.

This makes the results I'm seeing in my test make a lot more sense -- but then I no longer understand what the distinction is between a stacking context and a grouping property. Is it a distinction that's only relevant to SVG?

[frivoal]

Fixed the spec in 4ab5eed. Opened a separate issue (#6374) to follow up on overflow: clip.

If any other subthread of this issue needs continued discussion, I suggest opening a separate issue.

@dbaron, if that seems fine by you, can you close the issue?

[dbaron]

Seems fine to me.

[chrishtr]

but then I no longer understand what the distinction is between a stacking context and a grouping property. Is it a distinction that's only relevant to SVG?

The distinction is that not all grouping properties induce stacking contexts - in particular, overflow clipping. An unfortunate concession to web compatibility..