[csswg-drafts] [css-transforms][css-overflow] Need to better define how transform affects scrollable overflow. (#9458)

dbaron has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-transforms][css-overflow] Need to better define how transform affects scrollable overflow. ==
The descriptions of how CSS transforms affect scrollable overflow currently contain both (a) contradictions between specs (b) disagreements between specs and implementations and (c) lack of interoperability between implementations.

-----

The overflow module has [a definition of scrollable overflow](https://drafts.csswg.org/css-overflow-3/#scrollable) that basically says that transformed elements are considered only at the transformed position when computing scrollable overflow.  (This is considering only 2D transforms for now; there are some more interesting questions related to 3D transforms around both 3D scenes (as noted in the spec prose) and around perspective (see #3322).)

The transforms module, on the other hand, [contains](https://drafts.csswg.org/css-transforms-1/#module-interactions) both the sentence:

> Transforms affect the computation of the [scrollable overflow region](https://www.w3.org/TR/css-overflow-3/#scrollable-overflow-region) as described by [[CSS-OVERFLOW-3]](https://drafts.csswg.org/css-transforms-1/#biblio-css-overflow-3).

and then [later](https://drafts.csswg.org/css-transforms-1/#transform-rendering) has the paragraph (which I strongly suspect is much older, but haven't checked):

> For elements whose layout is governed by the CSS box model, the transform property does not affect the flow of the content surrounding the transformed element. However, the extent of the overflow area takes into account transformed elements. This behavior is similar to what happens when elements are offset via relative positioning. Therefore, if the value of the [overflow](https://drafts.csswg.org/css-overflow-3/#propdef-overflow) property is [scroll](https://drafts.csswg.org/css-overflow-3/#valdef-overflow-scroll) or [auto](https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto), scrollbars will appear as needed to see content that is transformed outside the visible area. Specifically, transforms can extend (but do not shrink) the size of the overflow area, which is computed as the union of the bounds of the elements before and after the application of transforms.

The last sentence specifically says the opposite of what the algorithm in the overflow spec does -- this sentence says that transformed elements influence the overflow area from *both* their untransformed position *and* their transformed position.

-----

So what do implementations do?

Let's start by considering [this testcase where the transformed element's original position causes a scrollbar, but transformed position does not](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22overflow%3A%20scroll%3B%20height%3A%20100px%3B%20width%3A%20300px%22%3E%0A%20%20%3Cdiv%20style%3D%22height%3A%2010px%22%3E%0A%20%20%20%20%3Cdiv%20style%3D%22background%3A%20blue%3B%20width%3A%2010px%3B%20height%3A%20200px%3B%20transform%3A%20translateY(-150px)%22%3E%3C%2Fdiv%3E%0A%20%20%3C%2Fdiv%3E%0A%3C%2Fdiv%3E) and then [this testcase where the transformed element's transformed position causes a scrollbar, but the original position does not](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22overflow%3A%20scroll%3B%20height%3A%20100px%3B%20width%3A%20300px%22%3E%0A%20%20%3Cdiv%20style%3D%22height%3A%2010px%22%3E%0A%20%20%20%20%3Cdiv%20style%3D%22background%3A%20blue%3B%20width%3A%2010px%3B%20height%3A%2050px%3B%20transform%3A%20translateY(100px)%22%3E%3C%2Fdiv%3E%0A%20%20%3C%2Fdiv%3E%0A%3C%2Fdiv%3E).  Based on these testcases, it appears that Chrome and Safari consider the transformed element at only its transformed position, whereas Firefox considers the transformed element at both its untransformed position and its transformed position.

However, we can consider the conceptually more complicated (but physically simpler) [testcase where the transformed element's original position also affects the size of an imaginary anonymous box inside of the scroll container](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22overflow%3A%20scroll%3B%20height%3A%20100px%3B%20width%3A%20300px%22%3E%0A%20%20%3Cdiv%20style%3D%22background%3A%20blue%3B%20width%3A%2010px%3B%20height%3A%20200px%3B%20transform%3A%20translateY(-150px)%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E), then the original position affects the height of the scrollbar in all three implementations.  This doesn't particularly surprise me (since it's essentially like there's a box on the inside of the scroll container that expands to hold its contents).  This remains true in [this testcase where the scrollable container is the viewport](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22background%3A%20blue%3B%20width%3A%2010px%3B%20height%3A%20150vh%3B%20transform%3A%20translateY(-75vh)%22%3E%3C%2Fdiv%3E%0A).

I don't think we have *any* specification text that explains the difference between these two scenarios, since I think we've generally avoided specifying that there's any anonymous box inside of a scrollable container.  It's not clear to me how we would specify that difference.

We can then consider the additional [testcase variant that is like the previous one, except that the transformed element is the root element](https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22background%3A%20aqua%3B%20width%3A%2010px%3B%20height%3A%201000px%3B%20transform%3A%20translateY(-900px)%22%3EHello%3C%2Fhtml%3E).  In this case Firefox and Safari no longer make the viewport scroll to reach the original position of the transformed root element, whereas Chrome does.  Without a coherent explanation for the difference between the first pair of scenarios (at least outside of Firefox, which largely (except for this case!) follows the original spec of using both the untransformed *and* the transformed positioned), it's hard to tell which behavior is correct for this case because we don't clearly know what to consider, and I also don't think we have a clear definition of what scrollable overflow area causes the viewport to be scrollable.

-----

For extra fun, a form of this *last* testcase is part of Interop2023 (as part of a test for something else, the interaction of transforms and background drawing on the root element), and was adjusted in web-platform-tests/wpt#36476 from requiring one behavior to almost requiring the other (modulo, I think, an error of 8px for the default margin on the root).  (I intend to propose modifying the test so either behavior passes.)

cc @mattwoodrow @nt1m @dholbert @emilio 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9458 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 October 2023 19:27:30 UTC