W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

[csswg-drafts] [css-transforms] Allow scale() to accept absolute lengths (#5273)

From: Christopher Kirk-Nielsen via GitHub <sysbot+gh@w3.org>
Date: Tue, 30 Jun 2020 14:45:02 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-648237305-1593528301-sysbot+gh@w3.org>
chriskirknielsen has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-transforms] Allow scale() to accept absolute lengths ==
The `scale()` function is useful and is used for lots of UI animations. However, sometimes, like in a ["FLIP" context](https://css-tricks.com/animating-layouts-with-the-flip-technique/), it would be great to be able to specify a length directly, and let the browser figure out the scaling ratio.

I am not certain what implications this would have, as I realise allowing lengths probably also means allowing an `auto` keyword in a scenario like `scale(200px, auto)` (equivalent to `scaleX(200px)`).

Would the browser be able to compute the element's original size (say 300x150), parse `scaleX(150px)`, calculate the `1/2` ratio and resolve to `scale(0.5)`? Seems like a bit of a stretch but I've run into this a few times and have tried to reach for this but always ended up with a JS-powered solution, or giving up and simplifying it to a fixed scale.

Aside from the FLIP technique, I've had the need for this when resizing an iframe I have no control over. I'd love to be able to say "fit this width and let the height be automatically determined", like `scaleX(100vw)`. (note: it's an iframe that is not responsive)

In my title, I mention "absolute lengths" because I saw that percentages are planned to be accepted as `100% == 1`, so it seems that this proposal should only encompass `px`, `em`, `vw`, etc.

Maybe I'm missing something crucial, but as I ran into this again today, so I figured I'd express the idea here!

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5273 using your GitHub account
Received on Tuesday, 30 June 2020 14:45:04 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:09 UTC