[csswg-drafts] Pull Request: [css + web-animations] Handle getKeyframes for CSSAnimations

andruud has just submitted a new pull request for https://github.com/w3c/csswg-drafts:

== [css + web-animations] Handle getKeyframes for CSSAnimations ==
In css-animations-2, instead of generating keyframes resembling
computed keyframes, generate specified keyframes. Computing the
keyframes at keyframe-creation-time creates too many questions
regarding when/how property values inside the keyframes are computed.
We can instead rely on the existing process for calculating computed
keyframes, and apply that process at the time getKeyframes is called.

This means that var() references (and dependencies in general, such
as 'em' units) remain until computed-keyframe-time.

This isn't a problem for shorthand expansion at keyframe-creation-time:
if there's a var() in a shorthand, it expands using the "pending
substitution value" [1] for its longhands.

We can continue to resolve logical properties to physical at keyframe-
creation-time as well, assuming 'direction' and 'writing-mode' are not
allowed in keyframes. (FWIW, it's not allowed in Blink, but I'm not
sure if this is spec'd).

In web-animations-1, in the algorithm for getKeyframes, we either
use the specified keyframes (+ compute missing offset) as the source,
or the computed keyframes, depending on circumstance. This
"circumstance" could definitely be tightened up a bit (instead of
referring to whether or not calls to setKeyframes have taken place),
but it probably makes sense to do this as a whole for all the
"tainting" behavior described by css-animations-2 (Animations chapter),
so I haven't tried to address that here.

I'm not sure if we need to explicitly add somewhere that the computed
keyframes contains the necessary offset/easing/composite values, or
if it's already "understood" that these exist also for computed
keyframes. (I didn't make a change here).

Finally, the fact that getKeyframes returns objects listed as
"dictionary ComputedKeyframe" is a bit awkward, since it's not
consistent with the spec's "main" definition of computed keyframes.
We should probably rename it.

[1] https://drafts.csswg.org/css-variables/#pending-substitution-value

See https://github.com/w3c/csswg-drafts/pull/5331

Received on Thursday, 16 July 2020 10:11:33 UTC