Re: [csswg-drafts] [css-transforms-2] proposal new transform-style: detached (#4242)

> Detaching any element would require an audit of all its ancestors to ensure they are not flattened.
> …
>  it makes sense to prevent detaching descendants of flattening nodes.

Agreed that this is a necessity.

The only way I could see this working (detaching despite flattening styles on an ancestor) is with a `position: fixed` behavior in addition to the 3D transform, where the layout of this element is unaffected by the surrounding layout/styles, and it instead becomes a child of the viewport/canvas within the rendering tree.

Unfortunately, the approach CSS has chosen is that for certain flattening properties, including [`transform`](, (and [`filter`]( being I think the only other one), even fixed position elements get trapped by the effect on the parent element.  There were lots of discussions around this at the time these effects were implemented & the decision was that following the DOM tree for these effects (so that a transform or filter affects all child elements, even fixed-position ones) was more important than maintaining the fixed position. It is too late to undo this now,  although this could conceivably be a case where a new `detached` value could change the behavior — though I'd probably see this as a new value for `position` rather than for `transform-style`.

On the other hand, if anyone was hoping to have the 3D effect preserved while still maintaining non-fixed positioning (contextual layout and scrolling and so on), you would need to define how the 3D construct gets passed through all parent styles or effects that usually cause flattening.

> assuming we had multiple descendants without flattening ancestor under a root with `transform-style: preserve-3d`

I'm not sure how this would be different compared to what happens currently when we have a `<body>` or `<div>` with `transform-style: preserve-3d` and then multiple children that have independent 3D transforms on them: both the transformed and untransformed children would collectively be rendered into the same 3D model (with the caveats that Chris mentioned about undefined rendering behavior with co-planar elements).

GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at using your GitHub account

Received on Friday, 15 November 2019 19:25:04 UTC