Re: [csswg-drafts] Interpolate values between breakpoints (#6245)

> Can we remove the `container-timeline-range` and have the 100% value refer to the container's containing block size. This is the size you would normally get by setting the container's width / height to 100%, right? So it seems like a logical 100% value.

It makes some sense, but the main use-case here is not %-of-auto interpolation, it's %-between-defined-breakpoints.

> additive CSS could also solve this if authors want a named timeline. 

I agree, we should work on additive cascade. Can we work on additive cascade? Let's do that. :)

<details>
<summary><q>I'm confused. This seems to be the opposite of what this issue originally asked for</q></summary>

There are a few overlapping issues here, sometimes in tension:

- There are advantages (at least in some cases) to referencing multiple 'keyframes' along the timeline, and multiple properties that move in concert. Both of those would push us towards an animation (or animation-like) model. 
- The downside is that all interpolated values end up in the animation origin, which is not a great place to manage all typography cascade-wise. Ideally we should _be able to_ keep values in the cascade, as part of the author origin, so it's possible to modify them from other selectors. That's the reason to encourage `mix()` where possible, though it might not be right for all use-cases.

I don't know if there's a 'right' way to balance those things. It's not that the animation version is useless without the inline version, but that it might be a bad idea to push authors towards _everything is an animation now_. 

Setting aside the cascade issue: from a syntax perspective, it's similar to discussing value-level vs at-rule media queries. The grouped at-rule is much simpler when managing multiple properties or breakpoints. The inline version becomes much simpler when managing a single property at a time.
</details>

But that's maybe a digression from the primary question here: _how do we define a range, and get our current position along that scale_? Once we have access to this sort of 'timeline', we can theoretically use it in various interpolation/animation contexts. Both `@timeline` and `timeline-*` handle that end of the problem, and should work in both `mix()` and `@keyframe` situations.

@emilio informally suggested a slightly different option here at TPAC - a calc-like function for accessing position in a range. Name TBD, but something like `position-of(<value>, <range-min>, <range-max>)` or `position-of(100cqi, 320px, 75ch)`. The returned value would be a (clamped?) fraction representing where the value `100cqi` falls along the range from `320px` to `75ch` (e.g. `0.5` if the value falls half-way between). Then we could apply that to control interpolation position in various contexts? This is basically 'just' the existing `calc()` solution, but simplified with a purpose-built function. The advantages are: 

- We're not limited to a single axis on a single container, but can mix and match container/viewport relative units
- We also get to define what value we are comparing to the range – we can use the current container size (`100cqi`), but we're not limited to it
- We can use the result in a wide variety of math contexts
- The results can be captured in custom properties and passed around the cascade as needed

I can see tradeoffs with any of the approaches. It might be worth bringing these options and their tradeoffs to the group for a decision?

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-1714120986 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 11 September 2023 15:29:44 UTC