Flex isn't interpolable with length in Grid because they cause trigger different layout behaviors, and figuring out a way to mix their effects with continuity would have been way too complicated for the benefit we'd get from it.

In stripes() flexes are much simpler (they just turn into lengths with a relatively trivial transform), so in theory they could be interpolable. You can't do it naively with a calc(), tho. Flex values are context-dependent, not just on the container size but also on the sum of all flex values in use in the context. A 10fr is large if it's accompanied by a 1fr, but small if accompanied by a 100fr. This means you have two general problems:

1. If the sums of flexes are different between the starting and ending values, the intermediate values will not reproduce what you'd naively expect if you just resolved the flexes to lengths and interpolated them.

2. 0fr has a fundamentally different behavior from any >0fr value.

We could fix both of these! For (1) we could normalize the flex sum to a fixed value (1fr?) at computed-value time. (This is probably a good idea anyway, since the currently-allowed interpolation of flex segments still suffers from this problem - 1fr, 4fr to 400fr, 100fr does not produce equal-sized stripes in the middle.) For (2) we could reproduce the behavior from flexbox where if the flex sum is <1, it represents only the corresponding portion of the free space, so .1fr, .2fr would only fill 30% of the space while 1fr, 2fr fills the whole thing. (We already have the "pretend there's a transparent 1fr stripe at the end, if they're all fixed" behavior; it can expand to activate whenever the sum is <1, taking the remainder to raise the sum to 1.)

These two fixes would give us a reasonable interpolation behavior, but we'd still have to deal with the mixing of flex/length issue, and define what happened in Grid if you mixed them. (Right now it's a syntax error, so we don't have to deal with it.)

Flex isn't interpolable with length in Grid because they cause trigger different layout behaviors, and figuring out a way to mix their effects with continuity would have been way too complicated for the benefit we'd get from it.

Can you elaborate on that? I would have hoped we'd be able to come up with a general solution for this issue. Though I'm currently not deep enough into the layout algorithm differences to make a reasonable point here.

In stripes() flexes are much simpler (they just turn into lengths with a relatively trivial transform), so in theory they could be interpolable. You can't do it naively with a calc(), tho. Flex values are context-dependent, not just on the container size but also on the sum of all flex values in use in the context.

Yes, I didn't explicitly mention that but my examples already take both into consideration.

This means you have two general problems:

1. If the sums of flexes are different between the starting and ending values, the intermediate values will _not_ reproduce what you'd naively expect if you just resolved the flexes to lengths and interpolated them.

2. 0fr has a fundamentally different behavior from any >0fr value.

We could fix both of these! For (1) we could normalize the flex sum to a fixed value (1fr?) at computed-value time. (This is probably a good idea anyway, since the currently-allowed interpolation of flex segments still suffers from this problem - 1fr, 4fr to 400fr, 100fr does not produce equal-sized stripes in the middle.)

Thanks for pointing that out! Normalizing them sounds reasonable to me. Though I wonder whether there might be use cases in which authors want to mix different sums of flex values to achieve a certain effect. If we normalize the sums, this isn't possible, but if we don't normalize, both can be achieved.

For (2) we could reproduce the behavior from flexbox where if the flex sum is <1, it represents only the corresponding portion of the free space, so .1fr, .2fr would only fill 30% of the space while 1fr, 2fr fills the whole thing. (We already have the "pretend there's a transparent 1fr stripe at the end, if they're all fixed" behavior; it can expand to activate whenever the sum is <1, taking the remainder to raise the sum to 1.)

That sounds totally reasonable. Though that's also already defined in the spec. by you and even shown in an example. Or is there still something missing?

These two fixes would give us a reasonable interpolation behavior, but we'd still have to deal with the mixing of flex/length issue, and define what happened in Grid if you mixed them. (Right now it's a syntax error, so we don't have to deal with it.)

It could still be defined as a syntax error in Grid for the time being and be discussed separately if needed. But as I said, ideally we could come up with a general solution for that.

Basically, the algorithm is already defined in a way to make interpolation between flex and other values possible. I.e. first substract any non-flex values from the total width and then split the remaining width according to the sizes of the flex values.
Once that's done, the flex values can be resolved against the non-flex units. (Those non-flex units don't necessarily have to be lengths, btw. Those could be angles as well, for example, or time spans.)

Sebastian

Can you elaborate on that? I would have hoped we'd be able to come up with a general solution for this issue. Though I'm currently not deep enough into the layout algorithm differences to make a reasonable point here.

The Grid layout algorithm invokes different algos if you have flexible lengths vs if you don't. There's not much to elaborate on, it just does different things.

Though I wonder whether there might be use cases in which authors want to mix different sums of flex values to achieve a certain effect. If we normalize the sums, this isn't possible, but if we don't normalize, both can be achieved.

The effect is really weird; if they want to do something weird they can do it by hand by adding more intermediate values. I don't think there's even a moderate use-case for the behavior to be done intentionally.

Though that's also already defined in the spec. by you and even shown in an example. Or is there still something missing?

Ahahaha, no, I just forgot I'd done that. Okay, good.

It could still be defined as a syntax error in Grid

Not... easily. Hm. I suppose I could reuse the machinery that %s do, where it's a syntax error to mix %s with a type if the % doesn't resolve to that type.

I suppose I could reuse the machinery that %s do

That's precisely what I was thinking: in <length-percentage>, the percentage resolves to a length, so they can be mixed in calc(). That's not the case in <length> | <percentage>.

So we could have <length-percentage-flex> where both percentages and flex resolve to lengths and can be mixed in calc(), and <length-percentage> | <flex> where they can't be mixed.

Interpolation of stripes() is in https://drafts.csswg.org/css-images-4/#interpolating-stripes, so relabeling.

Interpolation of stripes() is in https://drafts.csswg.org/css-images-4/#interpolating-stripes, so relabeling.

Of course! I am too focused on Backgrounds 4 lately. Sorry!

Sebastian

Though I wonder whether there might be use cases in which authors want to mix different sums of flex values to achieve a certain effect. If we normalize the sums, this isn't possible, but if we don't normalize, both can be achieved.

The effect is really weird; if they want to do something weird they can do it by hand by adding more intermediate values. I don't think there's even a moderate use-case for the behavior to be done intentionally.

The example you gave earlier, transitioning from 1fr, 4fr to 400fr, 100fr is also a weird one. Though I tend to agree that having 200.5fr, 52fr when halfway through the transition is probably not what authors would normally expect.

I think it's time to discuss this on a call. The proposed resolution is to adopt Tab's suggestions from this issue and from #8140. They are:

• Eagerly compute flex values to lengths (avoid transitioning between different flex sums)
• If flex sum is < 1, it only covers that portion of free space (remainder is pretended to be filled with transparent stripe; same behavior as in flexbox)

I explicitly excluded the issue around mixing flex and length values in Grid, as it seems to deserve a separate discussion.

Sebastian

1fr, 4fr to 400fr, 100fr does not produce equal-sized stripes in the middle

This kinda reminds me of aspect ratios (#4953). If we don't compute fr as lengths, maybe they should interpolate logarithmically? So the half point would be 20fr, 20fr.

Eagerly compute flex values to lengths

If a <length-percentage> stays as-is, I think <flex> should rather compute to a <length-percentage> instead of a <length>.

So 20px, 40%, 1fr, 3fr would compute to 20px, 40%, max(0px, calc(15% - 5px)), max(0px, calc(45% - 15px)).

No need to invoke log transitions to fix the behavior here. We want linear transitions, and that has a straightforward meaning, it's just that the actual flex values used are context-specific (they depend on the sum of flexes around them). Normalizing a >1 sum to =1 fixes that issue so flexes on either side of the transition can be directly compared/transitioned sensibly, and it basically matches how we deal with flexes elsewhere.

If a <length-percentage> stays as-is, I think <flex> should rather compute to a <length-percentage> instead of a <length>.

I'm not sure how I missed this comment, but yes, that makes perfect sense, @Loirooriol. Each flex computes to max(0, 100% - sum-of-percents - sum-of-fixed) * flex value / max(1, sum-of-flexes), and now it's a perfectly ordinary length-percentage with reasonable linear transitioning behavior.

The CSS Working Group just discussed [css-images-4][css-grid] Allow transitions between different types within `stripes()` , and agreed to the following:

• RESOLVED: fr values in stripes() convert to max(0, 100% - sum-of-percents - sum-of-fixed) * flex value / max(1, sum-of-flexes) (a <length-percentage>) when needed for interpolation