[css-overflow][css-transforms] Define how perspective transform interacts with scrollable overflow area

[johannesodland]

css-overflow-3 defines the interaction of transformed boxes on the scrollable overflow area as follows:

The border boxes of all boxes for which it is the containing block and whose border boxes are positioned not wholly outside its block-start or inline-start padding edges, accounting for transforms by projecting each box onto the plane of the element that establishes its 3D rendering context. [CSS3-TRANSFORMS]

The module does not define how perspective transforms and scroll position affect the scrollable overflow area.

When perspective transforms are used on a scroll-container, the projection of the border boxes onto the plane depends on the scroll position.

Example:

Given a scroll container with a perspective projection and an existing scrollable overflow area in the block axis (generated by contained line boxes or grid items all positioned at z=0).

The scroll container is scrolled to the start position.

Add an absolutely positioned box in the foreground (transformed by a positive z-coordinate) so that its border bottom edge is just below the existing scrollable overflow area. The projected border box would extend the scrollable overflow area by the current definition.

Scroll a small amount towards the end position. The projected box should now be well inside the existing scrollable overflow area.

This shows that projection and scroll position should be taken into account when calculating the scrollable overflow area.

Proposal:

Projection and scroll position should be taken into account when extending the scrollable overflow area accounting for transforms.

The scrollable overflow area should be extended by the smallest area that would allow all projected border boxes to stay within the block-start/inline-start padding edges when the container is scrolled to the block/inline start position, and within the block-end/inline-end padding edges when the container is scrolled to the block/inline end positions.

Firefox seem to account for the perspective transform and the scroll position. Chrome seems to account for the perspective transform, but only at the 'start' scroll position. Safari does not seem to take the projection into account at all.

[dbaron]

I'm not entirely sure what you're referring to as "projection transform" -- whether you're talking about the perspective property or values (like the perspective() function) of the transform property. There's a very important difference between them discussed in https://crbug.com/1264086 and the things it links to, which is that the perspective property applies in a different order relative to scroll offset. In that case, Firefox and Chrome behave differently, which is different from what you mention. (It's also possible there's a relationship to the big transform interop difference between WebKit and Chromium+Gecko.)

In hindsight, https://crbug.com/1264086 should probably have had a corresponding csswg-drafts issue a long time ago (but I don't think it does), but I suspect this issue is perhaps somewhat different.

[johannesodland]

I'm not entirely sure what you're referring to as "projection transform" -- whether you're talking about the perspective property or values (like the perspective() function) of the transform property.

That was a typo 😅. I was talking about the perspective transform applied due to setting the perspective property.

In hindsight, https://crbug.com/1264086 should probably have had a corresponding csswg-drafts issue a long time ago (but I don't think it does), but I suspect this issue is perhaps somewhat different.

I think this is related. The overflow module should describe how the UA should extend the scrollable overflow area, taking the perspective projection and possible scroll offsets into account.

After fixing my test, I realise that Chrome behaves different from Firefox. It seems like Chrome calculates the scrollable overflow area without taking the scroll offset into account (as if the scroll offset is 0,0. I'll edit the text to reflect that.

I think Firefox behaviour here is correct.

[dbaron]

I think this is probably a duplicate of #3322.