[css-transforms-3] Layout-affecting Transforms

[jensimmons]

Right now, if I apply a transform to content on a page, it does not affect layout. I would love for there to be a toggle for making the transformed content affect layout. Not for animations, necessarily, but because a lot of cool graphic design effects can be achieved with transforms... and yet, they are hard if not impossible to use, because the rest of the flow of the document is not affected.

For example: http://labs.jensimmons.com/2016/
Now I got away with this by applying a giant amount of padding-bottom, and changing it at many different breakpoints, but that solution was fiddly, fragile, and would not work in a CMS-context.

[fantasai]

Some earlier discussion on this topic: https://lists.w3.org/Archives/Member/w3c-css-wg/2007JulSep/0184.html

There were a number of issues raised in that discussion; some of them we have answers for now and others we don't really.

• Are margins rotated or not? Jen and I think the margins should be applied to the bounding box of the border box after the transform has been applied. This gives the author better control over spacing particularly in cases where there's rotation/skew; and also it's the only thing that makes sense for auto margins, which are important for alignment and spacing particularly in flexbox.
• We also think it would be a great idea to apply shape-outside, to give more control over how much space is taken up. This is particularly important for cases where the transform (as in Jen's example) results in a lot of blank space taking up vertical space, which then needs to be trimmed. (shape-outside would also be able to control the tight-wrap settings, which was an issue raised back in the 2007 discussions.)
• Margin collapsing? Applying margins after transforms allows margin collapsing to occur between siblings as normal. However, margins can't really collapse between the transformed box and its children.
• How does this work with positioning? Transforms has resolved that transformed boxes trap absolutely-positioned descendants, so that resolves that question. Wrt the transformed box itself, we would position the margin box (which is not transformed) as normal.
• Wrt auto-sizing, we think the layout of the box and its contents should be performed prior to transformation, just as it is for regular transforms, and then the transform is applied. The transform would only affect layout of surrounding content, not the size of the box itself. (For some of the more common rotation cases where there needs to be more layout interaction between the box, its contents, and the surrounding layout, writing-mode can be used.)

[dbaron]

We also only agreed to publish transforms as a working draft (see minutes 1, minutes 2 and minutes 3) provided that an issue was added saying that we wanted to address this. See the issue beginning "There are two roles" in the Introduction of the 2009-03-20 WD.

[dbaron]

Also, regarding margin collapsing: I think elements with layout-affecting transforms should probably establish new formatting contexts, since it doesn't make sense for floats outside to affect layout inside. Establishing a new formatting context implies rules for margin collapsing that I think are right: margins don't collapse across the boundary, but margins on the outside could still collapse with sibling margins.

[dbaron]

In the discussion in #5623, there was a request for use cases for layout-affecting transforms.

One case that I remember from the early discussion was for rotated table column headers. I think in many cases this is actually a transform, not a writing-mode. (For example, if the header has an emoji-like image within it.) Though I'm not 100% sure if this distinction is clear.

Another case I see from the initial comment above is effects like https://labs.jensimmons.com/2016/examples/rotation3.html . (I'm not sure which of the other examples are relevant, though there may be some.)

[andrewbaxter]

I have a wide logo image that I want vertical in mobile layouts for space saving purposes. I.e. I want to treat it like an element that was originally vertical. The only way to workarounds I can think of are hardcoding dimensions or using two images and swapping.