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

> The definition of palette-interpolate() is missing. I guess it will be added later.

We've gone ahead and removed it, with an issue asking if it's needed. It's not clear that it's worth the impl cost.

> I assume how interpolation functions are restricted in some contexts will be clarified in https://github.com/w3c/csswg-drafts/issues/10982.

Yeah, let's defer to that.

> This somewhat suggests that `<number>` is invalid, which it is not, and interpolating `<number>` does not seem to be a "niche" use case. The same applies for the description of calc-mix().

Mentioned `<number>` now.

> `<segment-options>` is a generic production but it is not recognized [as such](https://github.com/w3c/webref/blob/0bfe200daa66bf24e09a60f1daafb83843cdc5d3/ed/css/css-values-5.json#L417) by w3c/webref. Would it be possible to tweak the markup to avoid this? Perhaps by adding an informative class?

It's not generic, it's for these functions, and is typed as such.

> In my opinion, the description of the `<easing-source>` global option should be defined in a separate (preceding) section:

The description of `by <easing-function>` is in the previous section, because it's a global option applied to the progress input and belongs there, in "Specifying the Interpolation Progress". A plain `<easing-function>` in the first arg is a default for the between-stop options, so it's described over in "Defining the Interpolation Map".

> All interpolation functions requires two or more stops and do not allow omitting stop positions, while *-gradient() and linear() accept a single stop and allow omitting its position. Is it intentional?

Not intentional; we had it properly allow 1+ arguments in the generic grammar but forgot to apply it to the specific grammars. Fixed now.

> The value range of <input-position> is not explicitly defined.

Defined now, thanks.

> [7.2.1 Type Checking](https://drafts.csswg.org/css-values-5/#interpolation-validity) may suggest that it can also be `<'animation-timeline'>`:

No, it's just that `<'animation-timeline'>`, when it's valid, can be either. (It's only valid as a progress-source.)

> It also suggests that there are multiple `<progress-source>`:

No, the "each" is just distributing over the combination of progress-source and input-position. Only input-position can be multiple, as defined in the grammar.

> Do you consider `<progress-source>` and `<input-position>` as both representing progress values? Otherwise, how can you mix types when specifying progress? What does represent an input position specified with a proportional type?

Yes, they're both values on the same scale.

In all cases, it's a "progress scale" - 0-1 (or any value lower or higher, that's just the standard range). We *normalize* absolute values into this scale, using the "interpolation range". A proportional input position is just specifying a value on that scale directly.

> Should the : between `<input-position>{1,2}` and `<output-value>` always be serialized without a leading whitespace and with a trailing whitespace?

We haven't specified serialization yet, but yes, that's probably right (and `if()` should be consistent). Filed #12345 for us to remember to fix it later.

> I do not understand why the result type of calc-interpolate() must be the consistent type of its arguments made consistent with `<progress-source>`

You're right, it shouldn't be, because %s in progress-source and input-position don't resolve against the outer context at all. Fixed, with calc-interpolate() (the only interpolation function that *does* inherit a calculation context, since it's a math function) specifically saying that its progress-source and input-positions don't use the inherited context.

> can calc-interpolate() and calc-mix() be resolved during simplification?

Yes, this is specified in [7.3 Interpolation Resolution](https://drafts.csswg.org/css-values-5/#interpolation-resolution) for interpolation. It's now specified in "Mix Resolution" as well, using nearly identical wording.

> what is the default value of by `<easing-function>` and `<easing-function>`? by ease and ease?

`linear` for both. Specified now.

> should implicit stops be serialized with two explicit stops, like in `<*-gradient()>` and `<linear()>`?

Yes, we should match the other functions here when we specify interpolation in #12345.

> why isn't `<input-position>` optional (`{0,2}`), like in `<*-gradient()>` and `<linear()>`?

For now, because it wasn't clear how to specify it in the grammar.  We'll probably add something for it, see #12346

> I think this paragraph would be clearer by replacing not proportional with absolute:
> [...]
> (edit: I guess the second not proportional is required to allow declaring <progress-source> with <'animation-timeline'> with no absolute <input-position>.)

Correct, we needed to specifically refer to input sources that weren't proportional, excluding those that were absolute *and* proportional. Our other attempts at wording this, like "solely absolute" or something, were even worse.

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


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

Received on Monday, 16 June 2025 21:19:02 UTC