[csswg-drafts] should calc-size() and interpolate-size apply to grid-template-rows and grid-template-columns? (#10618)

dbaron has just created a new issue for https://github.com/w3c/csswg-drafts:

== should calc-size() and interpolate-size apply to grid-template-rows and grid-template-columns? ==
In https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2025918637 I made an initial proposal about which properties `calc-size()` should apply to, and in #10294 we decided to add an `interpolate-size` property as the primary opt-in mechanism for animations and transitions involving sizing keywords, rather than recommending the use of `calc-size()` around the values that should be interpolated.

The advantage of using `interpolate-size` as the opt-in rather than `calc-size()` is that it causes less to be broken in implementations that don't support the feature.  Only the animation is broken, but the endpoints of the animation still work fine.

The disadvantage of `interpolate-size` is that we no longer have the ability to roll out this feature one property at a time without having to worry about compatibility if we add more properties later.  In other words, when `calc-size()` was the opt-in mechanism, we could ship support for `height`/`width`/`inline-size`/`block-size` plus the same with `min-` or `max-` prefixes, and worry about `flex-basis` and grid later.  With `interpolate-size` we can't do that without potentially putting ourselves in a situation where we later need to add *another* value to `interpolate-size` to opt in to animations of those additional properties.

This concern led me to investigate implementing this for flex and grid.  I think flex turned out to be relatively doable (see https://crrev.com/c/5722209, https://crrev.com/c/5722835, and https://crrev.com/c/5715169), although the changes are still pending code review.

However, grid is more difficult.  I think I have an approach that works with `calc()` as it is implemented today.  However, once full unit algebra as specified in css-values-4 is implemented, this approach no longer works, because it depends (for its integration with the grid layout algorithm) on the `calc-size()` being a linear function of the sizing keyword result.  (This approach is sketched out in `TODO` comments in https://crrev.com/c/5726974, but I haven't yet implemented or tested it!)  In particular, it's not clear to me how to integrate with grid's distribution of width to tracks (including for items that span tracks) when sizing keywords are used in nonlinear ways that become possible once `calc()` has unit algebra.

(I also haven't thought about how to integrate the `fit-content()` function into `calc-size()` and `interpolate-size`, since I was attempting to implement only the other parts -- although I think the problems there are mainly syntactic rather than conceptual, to allow `fit-content()` as a `calc-size()` basis.)

My current inclination is, therefore, to decide to step back from trying to make these work for grid, and instead try to do an initial version of `calc-size()` and `interpolate-size` that works on `height`/`width`/`inline-size`/`block-size` plus the same with `min-` or `max-` prefixes, and on `flex-basis`.  This means that if we want to do grid integration later, we might have to use a new value on `interpolate-size`.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10618 using your GitHub account


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

Received on Wednesday, 24 July 2024 21:15:54 UTC