[css-transforms][css-overflow] Need to better define how transform affects scrollable overflow.

[dbaron]

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 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 both the sentence:

Transforms affect the computation of the scrollable overflow region as described by [CSS-OVERFLOW-3].

and then later 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 property is scroll or 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 and then this testcase where the transformed element's transformed position causes a scrollbar, but the original position does not. 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, 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.

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. 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

[bfgeek]

I'd strongly prefer if we keep Blink/WebKit behaviour here - e.g. only use the transformed position for the individual contribution. Developers often transform OOFs away to not contribute to overflow, e.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12449

... and Firefox is doing something funky in that it isn't treating the axes the same here.

For changing how an item contributes I'd like to rely on the (unnamed) #8361 property.

[css-meeting-bot]

The CSS Working Group just discussed [css-transforms][css-overflow] Need to better define how transform affects scrollable overflow..

The full IRC log of that discussion

<TabAtkins> dbaron: quesiton is how to do this quickly. I think I should just intro it and then discuss in the issue.
<TabAtkins> dbaron: Two underlying issues here, perhaps shoudl ahve separated them.
<TabAtkins> dbaron: One of the two affects many testcases you'd write for the second one.
<TabAtkins> dbaron: One problem, Transforms and Overflow both have a definitinon of how transforms affect scrolalble overflow, and they disagree
<TabAtkins> dbaron: It appears blink/webkit implement overflow, gecko implements transform
<TabAtkins> dbaron: Transform says transformed elements affet overflow both at their initial position and their transformed position
<TabAtkins> dbaron: Overflow says they only do it at their transformed position
<TabAtkins> dbaron: Ian has a comment that he strongly prefers the blink/webkit behavior, he thinks devs use this to avoid contributing to overflow sometimes
<TabAtkins> dbaron: Second issue, we keep running into issues where the fact that impls do scrolalble overflow by wrapping the thing inside the scrollbars with a block, and we somehow word the spec to avoid actually mentioning that
<TabAtkins> dbaron: Underneath, when impls do overflow by wrapping things in a block, if the last thing in the block is transformed up, if you use the Overflow spec dfn, there's nothing left to keep the scrollbar exposing that last bit. But impls do reserve that space.
<TabAtkins> dbaron: We keep working around the issue, but I think this isn't doable. And I don't think we can remove it. So we should define it.
<TabAtkins> dbaron: So this is complicated. I'd like people to say what they think in the issue.
<kizu> q+
<astearns> ack kizu
<TabAtkins> kizu: I'll comment in the issue. Note there's an Oriol proposal about ::contents pseudo, because I think this also includes this.
<kizu> Issue for the contents pseudo-element: github.com//issues/2406
<TabAtkins> astearns: Okay, taking this back to the issue. Thanks for the intro.
<TabAtkins> astearns: I'll leave it to david on whether ot break this into issuess
<TabAtkins> fantasai: As the editor of Overflow, I'd love it if we can settle on a description, this is one of a handful of things blocking CR