Closed dbaron closed 1 month ago
fwiw - I was relatively skeptical that calc-size()
could be made to work with the grid given how grid uses the intrinsic sizes (e.g. distributes differently based on size type etc). calc-size()
works on an individual element level, and starts to break down working across items (like for grid template).
Proposed resolution: The initial version of calc-size()
and interpolate-size
doesn't work on grid-template-columns
and grid-template-rows
.
The CSS Working Group just discussed should calc-size() and interpolate-size apply to grid-template-rows and grid-template-columns?
, and agreed to the following:
RESOLVED: remove grid-template properties from the list of properties that calc-size is valid for and that interpolate-size works on
This resolution matches the current state of the specs, since the edits in https://github.com/w3c/csswg-drafts/commit/aa94f650329b2f3096cbeddc6820100b30280baf did not cover the grid properties. (I didn't want to write a bunch of edits that I had proposed shouldn't be made!)
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 aninterpolate-size
property as the primary opt-in mechanism for animations and transitions involving sizing keywords, rather than recommending the use ofcalc-size()
around the values that should be interpolated.The advantage of using
interpolate-size
as the opt-in rather thancalc-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, whencalc-size()
was the opt-in mechanism, we could ship support forheight
/width
/inline-size
/block-size
plus the same withmin-
ormax-
prefixes, and worry aboutflex-basis
and grid later. Withinterpolate-size
we can't do that without potentially putting ourselves in a situation where we later need to add another value tointerpolate-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 thecalc-size()
being a linear function of the sizing keyword result. (This approach is sketched out inTODO
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 oncecalc()
has unit algebra.(I also haven't thought about how to integrate the
fit-content()
function intocalc-size()
andinterpolate-size
, since I was attempting to implement only the other parts -- although I think the problems there are mainly syntactic rather than conceptual, to allowfit-content()
as acalc-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()
andinterpolate-size
that works onheight
/width
/inline-size
/block-size
plus the same withmin-
ormax-
prefixes, and onflex-basis
. This means that if we want to do grid integration later, we might have to use a new value oninterpolate-size
.