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

@bfgeek and I have been noodling on this problem a bit, and I discussed it with @fantasai today as well. Here's a suggestion for a fix:

For each of the intrinsic sizing keywords, give them functional forms as well, like:

```
width: fit-content(scale 0%);
width: fit-content(scale 0% plus 200px);
```

The above is interpreted as "figure out the fit-content size, scale it by the `scale %` argument, and if provided, add the `plus <length-percentage>` argument".

Each function is interpolatable with itself, with the intermediate result obtained by interpolating the two arguments.

Using this, you can interpolate from "auto" to "0", at minimum, like:

```
details {
  transition: height;
  height: fit-content(scale 0%);
}
details[open] {
  height: fit-content(scale 100%);
}
```

Some additional details:

* this still counts as the element being intrinsically sized, so stuff like the way intrinsic sizing blocks margin collapsing (either thru, or from children out) continues to work the same. (Thus, `fit-content(scale 0%)` is slightly different, layoutwise, from `0px`, but in most cases it won't matter, or might even be an improvement.)
* the `plus` argument lets you transition to a length other than zero; to go from "auto" to "200px", for example, you could write them as `fit-content(scale 100%)` and `fit-content(scale 0% plus 200px)`. The intermediate result would be `fit-content(scale 50% plus 100px)`, giving you a nice linear interpolation of the height.
* we could *probably* do magic interpolation if one of the values is a fixed size, like going from `fit-content` to `0px`, by transforming both of the endpoints into the functional form. Depending on back-compat we might need to require one of the endpoints to be an intrinsic function, so like `fit-content(scale 100%)` to `0px` would work.
* I'm going with the funky `scale <per> plus <len-per>` syntax because the base size you want to interpolate to can legitimately be a percentage, so I need to distinguish that from the scaling argument. Very much open to better syntax suggestions, tho.
* We also need to avoid the `fit-content(<len-per>)` syntax that Grid already uses for track sizes, probably. (Sizing also has this, but it's not implemented anywhere. But we still likely don't want to interpret it totally differently between the two places.)
* All my examples show fit-content(), as that's the interpretation of `auto` we use when it's not definite, but we should allow `min-content()`, `max-content()`, and `stretch()` too, because the behavior is essentially identical and there can reasonably be use-cases for them, too.
* Should `auto()` exist too? Or maybe convert to `fit-content()`/`stretch()`? I'm somewhat hesitant to do this, since whether `auto` becomes definite or indefinite depends on context and that's kinda tricky. Inclined to say no, and require authors to use the function (or perhaps the specific intrinsic-sizing keyword, if we think we can get away with that compat-wise).

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


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

Received on Monday, 6 November 2023 21:39:30 UTC