should calc-size() and interpolate-size apply to grid-template-rows and grid-template-columns?

[dbaron]

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.

[bfgeek]

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).

[dbaron]

Proposed resolution: The initial version of calc-size() and interpolate-size doesn't work on grid-template-columns and grid-template-rows.

[css-meeting-bot]

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

The full IRC log of that discussion

<noamr> dbaron: hoping this would be quick. earlier in calc-size I've given a list of props it should work on
<noamr> dbaron: width/height/flex-sizes/grid-template-rows/template-columns/.. and equivalents. see in issue for full list
<noamr> dbaron: proposing to remove the grid ones for a few reasons. I thought it would be more doable than Ian
<noamr> dbaron: thought I was getting it done, but the approach doesn't work at all for division of length and unit algebra, both highly requested, speced but perhaps not implemented
<noamr> dbaron: basic conclusion after trying, there is no reasonable way to mix calc-size/interpolate-size with distribution over grid tracks, algebra over length
<noamr> dbaron: conclusion: not try to do it for grid properties, save initial version for the other properties and not the others
<noamr> dbaron: this might mean that if we figure this out in the future we might need to add a new opt-in value. we might not. but that's the down side
<noamr> dbaron: main reason to remove the grid props is that I don't see how to do it
<noamr> astearns: questions or concerns?
<TabAtkins> If dbaron can't figure it out, I doubt I could either, +1
<emilio> Sounds fair :)
<astearns> ack fantasai
<noamr> fantasai: how would this affect the syntax of the interpolate-size if we want to exend in the future?
<noamr> dbaron: we'd have to add a keyword like "also allow grid"
<noamr> fantasai: remind me of current values?
<noamr> dbaron: numeric only, allow-keywords
<TabAtkins> allow-keywords allow-grid-template
<TabAtkins> something like that
<noamr> fantasai: so we'll have "allow-grid" or something
<noamr> dbaron: something like that
<noamr> fantasai: sounds reasonable
<noamr> astearns: can this affect other props in the future. Anything left off the list dbaron?
<noamr> dbaron: only one possible candidate, something with column (column-width)?
<noamr> iank_: yes, it's column-width and the length properties
<noamr> astearns: it's possible we'd have some future extensions with more keywords
<noamr> astearns: seems reasonable if that ever happens
<noamr> dbaron: double hypthetical. need to do that if we found a way to do it and that by doing it would be a compat issue. for columns that's unlikely a compat issue
<noamr> astearns: any other q or comment?
<noamr> astearn: proposed resolution: remove grid-template properties from the list of properties that calc-size is valid for and that interpolate-size works on
<noamr> astearns: objections to removing grid-template-* properties from this feature?
<astearns> RESOLVED: remove grid-template properties from the list of properties that calc-size is valid for and that interpolate-size works on
<masonf> (the all-caps RESOLVED matters)

[dbaron]

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!)