[css-grid-1] Interpolating track listings

[fantasai]

Currently grid-template-rows/columns interpolate “per computed value”, which means that if the number of tracks differs, or any track changes to/from a particular keyword value to any other value, or if a line name is added/removed at any position, the entire track listing is interpolated as “discrete”. But we have some more granular options:

• Check interpolation type per track, rather than for the entire list, before falling back to discrete. I.e. a length-percentage track can animate between two values while an adjacent auto track flips discretely to min-content.
• Allow discrete interpolation of line name changes independently of track sizes.
• Allow interpolation of mismatched track list lengths, by filling in missing values from grid-auto-rows/columns.

Wanted to hear back from implementers what they think is reasonable here. CC @MatsPalmgren @mrego @javifernandez @birtles

[tabatkins]

Note that in w3c/svgwg#543 implementors were unhappy about "splitting up" the interpolation of a single property such that some parts could interpolate discretely due to a mismatch while the rest still interpolated normally. (The end result they settled on looks kinda like "splitting up", because they decided to interpolate the arc flags as <integer>, but technically it's interpolating "normally".)

I'd like to be consistent across properties for this sort of thing.

[tabatkins]

That said, I think the third bullet point (consult grid-auto-rows for information) is a no-go; interpolation shouldn't depend on other properties at all.

If we did decide to interpolate piecemeal, I'm fine with either of the first two bullet points; could take or leave either of them.

[birtles]

Note that in w3c/svgwg#543 implementors were unhappy about "splitting up" the interpolation of a single property such that some parts could interpolate discretely due to a mismatch while the rest still interpolated normally.

Specifically, I think Blink had difficulty with this for path commands in particular. In Gecko/Servo it makes no difference--rather we had to add code to achieve the less granular fallback behavior.

Going forward, I think we should prefer more localized/granular fallback for the reasons I outlined in that issue.

That said, I definitely agree we want to avoid dependencies between properties when doing interpolation.

[css-meeting-bot]

The CSS Working Group just discussed Interpolating track listings, and agreed to the following:

• RESOLVED: Fully specify the first 2 bullet points and leave it at that for this level

The full IRC log of that discussion

<dael> Topic: Interpolating track listings
<dael> github: https://github.com//issues/3201
<dael> fantasai: How do we interpole track listings. Current definition is basic, there are options to make it nicer
<dael> fantasai: Asking WG what do they want to put in here.
<dael> fantasai: I've tried to ping people for opinions but I'm not getting info
<dael> TabAtkins: The templates have a lot of different information and being inconsistant in one part means you have to do the whole thing descretely. Options in issue for level of granularity. More fine then one difference makes thing go.
<dael> TabAtkins: 3rd point is the only no go to me. All others are reasonable to me if someone likes them
<dael> astearns: There is reasonable to TabAtkins . There's also willing to implement. Do we have both?
<dael> TabAtkins: I'd have to ping Igalia folk
<dael> rego: I think we don't have support for animations on these prop in blink
<dael> fantasai: What would you like spec to say?
<dael> rego: I don't know how complex the different options will be. We can have something better here, but not sure how it can be done
<dael> fantasai: Okay. I think Moz is in process of impl this.
<dael> Rossen: Is the 3rd option...
<dael> fantasai: It's user checkboxes, not radio buttons. Just to be clear
<dael> Rossen: Trying to figure out what brian was talking about in terms of current differences between Gecko and Blink and his preference for less granular fallback
<fantasai> s/It's user/The options are/
<dael> Rossen: Looking through options it sounds like if we allow discrete independent of tracks we solve this. They both sound fine
<dael> fantasai: I would like this closed by next week
<dael> Rossen: I'm trying to figure out implications of 3rd. If we need it at all. Since we have Igalia who is interested in trying that in Blink perhaps we can try and resolve now. Or push to next week. Either is fine.
<dael> Rossen: I'm trying to tease apart technical implications
<dael> rego: We can discuss the 3rd one. THat one prop depends on another doesn't seem good idea. Other 2 I don't have opinion
<dael> Rossen: I think the first 2 are straightforward and doable. 3rd I have reservations
<dael> Rossen: If this is acceptable for now we can try and do that
<dael> Rossen: fantasai is the idea we want all 3?
<dael> fantasai: The idea is we want this defined.
<rego> s/We can discuss/We can discard/
<dael> Rossen: Good. Take one by one? I think first 2 are non-controversial. 3rd we can leave it or fork it
<dael> fantasai: We can resolve to do first 2 and not 3rd. These are the options I can think of we have to decide yes/no on each
<dael> astearns: And 3rd is something we can add later if it proves feasible.
<dael> fantasai: Prob possible
<dael> Rossen: Good to see what that 3rd option blocks in terms of use cases. First 2 will solve a lot of use cases. We can wait and see if 3rd is required.
<dael> astearns: Prop: Fully specify the first 2 bullet points and leave it at that for this level
<dael> astearns: Obj?
<dael> RESOLVED: Fully specify the first 2 bullet points and leave it at that for this level