Repository navigation
[css-easing-1] Clarify computed values and serialization #8723
Description
The CSS Easing spec has a section on serialization, however this section doesn't distinguish between specified and computed values (and seems to be defining the computed value serialization). Should there be any differences between these two? E.g.
- Should specified values of
step-endandstep-startbe serialized as themselves rather than as asteps()function? - Should the
jump-endandendkeywords be kept as distinct specified values?
Relatedly, the spec seems a bit confused about the computed/serialized values for start/end/jump-start/jump-end: the serializations of the “end” values are collapsed to a single serialization, but not the “start” values. I think
jump-start/jump-endshould compute tostart/endor vice versa (unsure which we prefer).- the computed value serialization should fall out from that
Activity
birtles commentedon Apr 15, 2023
In general it's easier for authors if they don't need to write parsers for multiple potential outputs and can always assume a certain format.
That said, Chrome appears not to support that: https://wpt.fyi/results/css/css-easing/step-timing-functions-syntax.html?label=experimental&label=master&aligned
Yes. We'd like to normalize to
jump-endbut in the interests of Web compat, we shouldn't unless we have data to indicate it's safe to do so.That's intentional. We'd like to use
jump-*values everywhere but we can't because of Web compat. The only case where we can isend/jump-endbecause it happens to be the default value so, according to standard CSS serialization rules, we omit it.