[css-transforms][css-overflow] Need to better define how transform affects scrollable overflow.
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- css
- Domain
- documentation
Research direction
Compare the CSS Overflow 3 scrollable-overflow definition with the CSS Transforms 1 module-interactions and transform-rendering sections, using the linked testcases to characterize current behavior. Review web-platform-tests/wpt#36476 and the Interop2023 root-element case; done means the specs explain the scenarios coherently and the test expectations are aligned with the resolution.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 24
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from w3c/csswg-drafts
-
Agenda+ css-sizing-4 css-values-5
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
w3c/csswg-drafts#14502 · 1 reaction ·
-
css-values-5 editorial Needs Edits
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
w3c/csswg-drafts#14498 · 2 comments ·
-
css-overflow-4 topic: line-clamp
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
w3c/csswg-drafts#14485 · 1 comment ·
-
Administrative Tracker css-values-4
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
w3c/csswg-drafts#14482 · 4 comments · 1 reaction ·
-
css-values-5 Needs Edits
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
w3c/csswg-drafts#14466 ·
All issues in w3c/csswg-drafts
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bancolombia/sentinel#22 ·
-
test md OpenCI
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
optimization optimization:agents-md-curator
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
githubnext/gh-aw-cao#13143 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
objectionary/hone-maven-plugin#1061 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
redhat-developer/rhdh-plugins#4887 · 2 comments ·