[css-transforms-1] How should transforms affect geometry of boxes, w.rt. overflow

[atanassov]

In the case when a child box gets transformed so that it fully fits inside its parent box, does it's size get affected by scrollbars or not?

See example: https://jsfiddle.net/gpqkzth1/

[smfr]

We talked about this in Seattle but did not come to a conclusion, if I recall.

[atanassov]

Your recollection is correct. The issue here was meant to capture the fact we still need a solution :)

[smfr]

The original issue: https://drafts.csswg.org/css-transforms/issues-wd-2013.html#issue-48
Seattle resolution: https://lists.w3.org/Archives/Public/www-style/2017Feb/0054.html

[css-meeting-bot]

The CSS Working Group just discussed How transforms affect overflow geometry, and agreed to the following resolutions:

RESOLVED: Overflow bounds that are computed at the end of layout can increase (but not decrease) by  paint-level effects such as transforms.

The full IRC log of that discussion

<TabAtkins> Topic: How transforms affect overflow geometry
<TabAtkins> GitHub Topic: https://github.com/w3c/csswg-drafts/issues/901
<TabAtkins> [we all lament not having github-bot previously]
<TabAtkins> Rossen: [draws example on whiteboard]
<TabAtkins> Rossen: Opposite, start with something small with a 50% width, scale it large to overflow and trigger a scrollbar, do we trigger a scrollbar and resize the box?
<TabAtkins> Rossen: Edge flips the scrollbar on once, that's it, nd doesn't recompute the sizes.
<TabAtkins> ChrisL: A common problem is one that would fit except that the scrollbars are there.
<TabAtkins> Rossen: That only happens if you're throwing transforms around.
<TabAtkins> flackr: In this example it's just something that was big beforehand.
<TabAtkins> flackr: And this happens with normal layout too, right?
<TabAtkins> TabAtkins: Yeah, everyone settles on displaying the scrollbar somehow.
<smfr> https://drafts.csswg.org/css-transforms/issues-wd-2013.html#issue-48
<TabAtkins> [reviews the minutes of the reoslutions for issue 48]
<TabAtkins> Rossen: So in this example (example scaled down) the layout bounds are still tall and trigger scrollbars.
<TabAtkins> smfr: Is that the same as saying that overflow bounds are the union of the untransformed and transformed boxes?
<TabAtkins> smfr: More detail - in a tree of transforms, you compute a bounding box without transforms, and one with transforms, and take the union.
<smfr> https://lists.w3.org/Archives/Public/www-style/2015Nov/0167.html
<TabAtkins> Rossen: Corollary: if you discover your transform bounds fit entirely in your box, you can omit the scrollbars.
<TabAtkins> TabAtkins: No, that violates the "can increase bounds, not decrease".
<TabAtkins> RESOLVED: Overflow bounds that are computed at the end of layout can increase (but not decrease) by  paint-level effects such as transforms.
<smfr> https://bug1198135.bmoattachments.org/attachment.cgi?id=8684006
<TabAtkins> smfr: I'm concerned about the issue in the mail I just posted - if perspective can cause overflow bounds to increase, it might result in horizontal scrollbars in some cases that aren't there today.
<TabAtkins> smfr: But apparently Firefox already does that, so maybe we're okay.
<TabAtkins> Rossen: Anyway, this is a level 2 issue, since it's a 3d issue. We're good for level 1.