Currently our handling of keyframe arguments is not spec-compliant. The full list of violations is long, but the TL;DR is that we:

1. Resolve the CSS property/value pairs too early, when processing keyframe arguments. The spec says they should be kept as provided to be returned in KeyframeEffectReadOnly::getKeyframes(), and resolved only when a visual output (e.g. a frame) is required.

2. Resolve the CSS property/value pairs incorrectly; each property is resolved in iteration order, new shorthands/longhands override older ones, etc. The spec has specific rules on how to resolve conflicting shorthands/longhands.

3. Cache the resolved CSS property/values for the entire animation, which likely (unchecked) means we resolve CSS variables when the keyframes are parsed and don't revisit them.

4. Something I've forgotten. We're really off spec :(.

We need to:

  i. Keep the keyframes around un-resolved so that getKeyframes() can return the correct value.
  ii. Figure out if caching is required for adequate performance.
    a) If so, implement some sort of update callback for CSS variables and the future ability to provide JS hooks for CSS since those could also change.
    b) If not, remove the caching layer and just re-compute keyframes each frame.
  iii. Probably reject compositing animations which have CSS values that can change?
  iv. Something else I've forgotten.