3D CSS animation causes scrollHeight to change
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
People
(Reporter: mozilla2, Unassigned)
References
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: view the attached file, scroll to the bottom Actual results: firefox resizes the page constantly Expected results: the page should be a stable size? It is in Safari and Chrome. Of course it could be yet another CSS bug on my part.
Reporter | ||
Updated•12 years ago
|
![]() |
||
Updated•12 years ago
|
Comment 1•12 years ago
|
||
I see this on trunk as well.
![]() |
||
Comment 2•12 years ago
|
||
Dup Bug 456497?
Comment 3•12 years ago
|
||
Bug 456497 says that all the browser have the same behavior. This does not seem to be the case for this bug or that the data from 456497 comment 3 is dated.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
I can still reproduce this. Seems more like a layout thing so moving there. Also feel like this is a duplicate but I can't find anything.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Comment 6•1 year ago
|
||
Here's a screenshot showing the behavioral difference with testcase 2.
I don't have the transform css specs paged into my head right now, but a quick skim at
https://drafts.csswg.org/css-transforms-1
https://drafts.csswg.org/css-transforms-2
doesn't seem to really clarify what the expected outcome is here. To the extent that it is clear, it seems like maybe Firefox's behavior (creating scrollable overflow for the whole transformed element) is correct.
The only mention of "scrollable overflow" that I see is here:
https://drafts.csswg.org/css-transforms-1/#module-interactions
Transforms affect the computation of the scrollable overflow region
Unfortunately transforms-2 (which defines perspective
and 3d transform stuff) doesn't mention scrollable overflow at all.
Comment 7•1 year ago
|
||
But yeah, transforms-1 pretty clearly says that we should create scrollbars to ensure that the transformed content is visible:
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.
That's what we're doing (it's a little tricky to see in the original testcase since some of the content is transparent, but testcase 2 makes it clearer).
Comment 8•1 year ago
|
||
Here's a simpler testcase, using translate3d()
with x, y, and z components.
It looks like the Z axis is where the behavior difference arises. As noted in the testcase, Firefox creates scrollbars to scroll all three of these scrollable areas (in the inline/block end direction) to be able to see the overflowing portion of the blue shape, far enough to reach the endwards lime border.
In other browsers, the scrollable overflow is not created in the 3rd box here.
Comment 9•1 year ago
|
||
I filed https://github.com/w3c/csswg-drafts/issues/8851 to seek clarification in the spec.
Comment 10•1 year ago
|
||
Per https://github.com/w3c/csswg-drafts/issues/8851#issuecomment-1552249496 on the spec issue, it sounds like Firefox is correct here, and Chromium folks consider their behavior to be a bug that should be fixed (in https://bugs.chromium.org/p/chromium/issues/detail?id=1264086 ).
--> Closing as INVALID, since it seems we're correct on this point.
Description
•