Re: [csswg-drafts] [css-transitions] Transition to height (or width) "auto" (#626)

Yeah, doing "auto to auto" is a substantially harder problem. calc-size() just lets us abstractly manipulate a keyword value without having to actually know what it's value *is* - we can just say "whatever `auto` turns into, i'm scaling it from *1 to *0" or whatever, and the rest of the transition behavior falls out of that.

"auto to auto", tho, requires somehow capturing the notion of "auto at time X" vs "auto at time Y", and preserving those two concepts in the style system in some way such that we can run a transition that includes both of those values long after "time X" and "time Y" have passed. And also *recognizing* that `auto` has changed its value (something only known at layout time) when it's time to trigger transitions (which is computed-value time, preceding layout).

We've gone to some effort to *partially* solve that latter problem, for a restricted set of properties in a restricted context, for Anchor Positioning - you *can* transition an abspos's position when its anchor moves around or resizes, because we wave a magic wand and say that `anchor()` functions effectively "cycle back" and pretend that some layout-time information (the anchor's size/position) was actually computed-value time information, which we can do *because* we have some restrictions that ensure the abspos doesn't even *start* to lay out until *after* the anchor is completely finished with layout.

And Container Queries *also* solve a restricted form of this - if you have `width: 50cqw; transition: width 1s;`, you'll trigger a `width` transition if your container's width changes, because `cq*` units have a similar "pretend layout info is computed-value info", and again are *capable* of doing so because the container is prevented from having its size depend on its children, so we can fully resolve the container's size before we even start laying out the children.

Both of these cases (and they're the only two cases that cover this sort of thing, currently), depend heavily on certain timing assumptions we can make that are guaranteed due to how those particular features work. In the *general* case, we can't do this.

The only way around it is to impose a temporal ordering on the values, such that one can't affect the other. You can do that by invoking JS, for example - measure the size, make a change, then measure the size again, and *then* kick off a transition between those two values. JS's nature allows this to work; CSS mostly pretends time doesn't exist, and can't.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2052397014 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 12 April 2024 19:21:04 UTC