- From: Guillaume via GitHub <noreply@w3.org>
- Date: Fri, 13 Jun 2025 07:14:34 +0000
- To: public-css-archive@w3.org
I do not understand why the result type of `calc-interpolate()` must be the consistent type of its arguments **made consistent with `<progress-source>`** ... unless I am misunderstanding how to determine the type of a `<percentage>` in a math function replacing `<progress-source>`: I think it must resolve to `<number>`, based on `<progress-source>` as the context. Below are some questions that are obviously not important at this stage, which could be answered later in separate issues, but which could also be answered on the fly in future edits: - can `calc-interpolate()` and `calc-mix()` be resolved during simplification? - what is the default value of `by <easing-function>` and `<easing-function>`? `by ease` and `ease`? - should implicit stops be serialized with two explicit stops, like in `<*-gradient()>` and `<linear()>`? - why isn't `<input-position>` optional (`{0,2}`), like in `<*-gradient()>` and `<linear()>`? I think this paragraph would be clearer by replacing *not proportional* with *absolute*: > [..] all `<progress-source>` and `<input-position>` values that are not proportional must have a consistent type for the notation to be valid. Additionally, an interpolation notation whose `<progress-source>` is not proportional must have at least one absolute `<input-position>` (in order to define the interpolation range), or else the notation is invalid. And *"analogous to `animation-easing`"* should be *"analogous to `animation-timing-function`"*. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2969347179 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 13 June 2025 07:14:35 UTC