should it be possible for an element with contain:paint to be part of a transform-style:preserve-3d scene? #6202
Comments
|
I'm not sure. Given that paint-contained element cannot have visible overflow, is there really an issue? 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'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? |
|
I agree that And I think it makes sense for |
|
The CSS Working Group just discussed
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? |
|
Filed #6373 on |
|
To follow up on this mornings discussion -- I noticed that the compositing spec says (for HTML but not SVG):
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? |
|
Seems fine to me. |
The distinction is that not all grouping properties induce stacking contexts - in particular, overflow clipping. An unfortunate concession to web compatibility.. |
Right now the specs for
contain:paintand fortransform-styleallow an element withcontain: paintto be part of a 3D scene. If such an element both hastransform-style: preserve-3dand has a parent that does, then this means that its children (or further descendants, if the children havetransform-style: preserve-3d) are rendered as part of its parent's (or further ancestor's, if the ancestor chain hastransform-style: preserve-3dfurther up) 3D scene.While the intended guarantees of
contain: paintaren'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?
The text was updated successfully, but these errors were encountered: