[css-grid] Interpolate repeat()

[BorisChiou]

We have a discussion about interpolating track listings (#3201), but the current spec doesn't have clear definition of how to interpolate repeat(). (Or maybe I misread it. Please feel free to close it if there is a duplicated issue or they are well-defined already.)

Example 1:

repeat(2, 2fr 30px)
repeat(2, 3fr 40px)

They use the same repeat count, so doing interpolation between them is ok to me.

Example 2:

repeat(2, 2fr 30px)
repeat(4, 40px)

Their resolved/expanded track lists have the same length, so people may think they are animatable. However, we do interpolation by computed values, so it seems we shouldn't expand the list during interpolation, which means they are not animatable? I'm not sure which behavior is expected.

Example 3:

repeat(auto-fill, 10px)
repeat(auto-fill, 20px)

Even if the keyword is the same it can result in different number of tracks. For both auto-fit/fill, the number of columns isn't known until you do layout since it depends on the container size, item placement and other factors. Therefore, we fallback to discrete in this case. Right?

Thanks.
cc @MatsPalmgren @birtles

[BorisChiou]

I will add some test cases to wpt by Firefox Bug 1348519. Please feel free to update them.

[tabatkins]

Yup, this is unspecified and should be fixed. My intuitions:

repeat(2, 2fr 30px)
repeat(2, 3fr 40px)

This should definitely interpolate. Same N, contained track list is same length and item-wise interpolable, everything's A-OK.

repeat(2, 2fr 30px)
repeat(4, 40px)

I could go either way. Fine with this being interpolable in theory (same lengths once expanded, expanded track list is item-wise interpolable), but I'd also be fine being simple here and saying no if it would cause implementation difficulties. I'm generally in favor of keeping interpolation simple and obvious if possible, which leans me toward saying "no", and requiring authors to write the second as repeat(2, 40px 40px) if they want it to interpolate.

repeat(auto-fill, 10px)
repeat(auto-fill, 20px)

I think these should interpolate, going from 10px to 20px. Yes, the number of tracks can change, but I think that's fine? Track-number determination doesn't happen until used-value time, so interpolation doesn't need to care about it. Leaning on my "should be simple and obvious", these definitely look like they're compatible with each other.

---

So all in all, the rule I lean towards is "first argument must be identical, second argument must be interpolable as a computed track list; else discrete". So that's yes on Example 1, no on Example 2, and yes on Example 3.

[MatsPalmgren]

How about:

repeat(2, 2fr 30px)
repeat(4, 40px 40px)

and

repeat(auto-fill, 10px)
repeat(auto-fit, 20px)

It might be convenient to authors if we could treat the first argument to repeat() as just another component that is animatable if the 2nd argument has the same length. My first example would then animate as repeat(2, ...) repeat(3, ...) repeat(4, ...). My second example would animate the first argument discretely while still animating 10px -> 20px as a <length>. (<integer> -> auto-fill/fit would also be discrete)

[tabatkins]

Hm. My first instinct is to say no to both, and require an exact match on the first arg.

But that's not actually a very consistent position; if I'm fine with repeat(auto-fill, 20px) => repeat(auto-fill, 10px), which at used-value time (if we pretend a 40px container) is equivalent to repeat(2, 20px) => repeat(4, 10px), then I should be fine with that 2 => 4 transition directly.

So I think I agree. We can do either of the following:

• require that the first arg is a number, and identical between start/end; different values, or keyword values, both go discrete
• allow any values for the first arg: if they've the same value they transition by doing nothing; if they're different numbers they transition as integers; otherwise the whole function transitions discretely

[css-meeting-bot]

The CSS Working Group just discussed Interpolate repeat(), and agreed to the following:

• RESOLVED: Define repeat interpolation using the more restrictive rule in https://github.com/w3c/csswg-drafts/issues/3503#issuecomment-453674839

The full IRC log of that discussion

<dael> Topic: Interpolate repeat()
<dael> Github: https://github.com//issues/3503#issuecomment-453674839
<fantasai> https://github.com//issues/3503#issuecomment-453674839
<gregwhitworth> iank_: yes - we can chat about it a little bit, I'll do a phone chat with Alek as well
<dael> TabAtkins: Question was raised by Boris. How are repeat functions interpolated in grid template rows
<fantasai> s/Alek/Aleks/
<dael> TabAtkins: It's retained in computed values bc some can't be resolved at computed value time. Computed value animaiton runs on will have repeat functions. How do they interpolate. This isn't in spec.
<dael> TabAtkins: They have 2 functions. After some discussion in issue and some nice examples there's 2 options that are consistent with how we interpolate
<dael> TabAtkins: First is we're very restrictive. To get smooth interpolation first arg must be a number and track listing must have same number of things. 2, 10px, 10px to 2, 20px, 20px will be smooth. If you have auto fit no smooth
<dael> TabAtkins: Other poss is we allow any values for first. If same transition by doing nothing. If they're numbers and diff they transition as int. If you try and go into to keyword it goes discrete.
<dael> TabAtkins: Still require track listing match with normal transitioning rules. You could not go from a repeat 4, 10 px to repeat 2, 10px, 10px. An auto fit and auto fill we can't match and I don't like special casing that
<dael> TabAtkins: I propose: We require that either the first arg be the same value or both int. Track listings must be interpolable normally
<dael> fantasai: 2 proposal. Main difference is the first one you can only interpolate if it results in same # of tracks. 2nd version we try and follow value interp patterns we have and that allows more possibilities. Disadvantage to that is you're not interpolate between # tracks and therefore position of elements can change.
<dael> fantasai: Do we want as much smooth in value space but have layout discontinuous or do we want to align what's possible to interopolate in layout with value space
<dael> TabAtkins: With caveat that discontinuous layout does happen if you end up in discrete. We do allow int based on grid positions we also can have skipping. THis is the whole grid, but similar in idea
<dael> astearns: I think I would like to have many example is spec whichever we choose
<dael> TabAtkins: Yep
<dael> fantasai: Anyone besides me and TabAtkins have an opinion or want more time?
<dael> astearns: fantasai do you have a preference?
<dael> fantasai: From what I know I'd go with first option. More restrictive.
<dael> fantasai: It seems like interpolating in value space and having things jump around, I'm not sure it would be that great. I don't feel very strongly b/c I don't understand strongly impl for layout system. I'd do whatever Mats thinks is right
<dael> fantasai: We can poke Mats. Any other opinions?
<dael> astearns: Often we will be more restrictive to begin with and then later add smooth interpolation to things that were previously discrete. THat's an argument to more restrictive because we can get to more liberal eventually
<dael> astearns: Other opinions?
<dael> astearns: Am I correct about being able to loosen in the future?
<dael> fantasai: I think you're correct
<dael> astearns: Prop: Define repeat interpolation using the more restrictive rule in https://github.com//issues/3503#issuecomment-453674839
<dael> astearns: Objections?
<dael> RESOLVED: Define repeat interpolation using the more restrictive rule in https://github.com//issues/3503#issuecomment-453674839

[fantasai]

Alright, fixed in 2e57e1e ! @MatsPalmgren @BorisChiou Let us know if the edits seem satisfactory.