- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Mar 2023 22:43:29 +0000
- To: public-css-archive@w3.org
> 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](https://drafts.csswg.org/css-images-4/#example-465c1bec). 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 -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8622#issuecomment-1483530692 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 March 2023 22:43:31 UTC