[csswg-drafts] [css-animations-2][scroll-animations-1] Keyframe ordering and ordering requirements (#8507)

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-animations-2][scroll-animations-1] Keyframe ordering and ordering requirements ==
# Overview

We need to define the order of keyframes from CSS animations and any requirements when constructing JS animations. Prior to [timeline range keyframe selectors](https://www.w3.org/TR/scroll-animations-1/#named-range-keyframes) we have the following rules:

[css-animations-2 Section 3. Keyframes](https://drafts.csswg.org/css-animations-2/#keyframes) performs a stable sort by offset (step 6), and merges keyframes with matching keyframe offset, timing function and composite (step 6.4). The result is exposed via the [web-animations-1 getKeyframes](https://drafts.csswg.org/web-animations-1/) method.

[web-animations-1 Section 6.6.3. Processing a keyframes argument](https://drafts.csswg.org/web-animations-1/#processing-a-keyframes-argument) procedure to [process a keyframes argument](https://drafts.csswg.org/web-animations-1/#process-a-keyframes-argument) step 6 throws a TypeError if the supplied offsets of the keyframes are not sorted.

With [timeline range keyframe selectors](https://www.w3.org/TR/scroll-animations-1/#named-range-keyframes) the order of keyframes is not known until after layout and may change with changes to the layout. As such, we have to decide how to handle this.

I wrote a short demo to show the observed keyframes at https://jsbin.com/zofukin/edit?html,css,js,output

# Proposal

For css animations:
1. just as differences in composite and the timing function do not allow two keyframe blocks to be merged, we should consider named range offsets to only be mergeable with the exact same specified named range offset.
2. Keyframes should continue to be sorted by a stable sort, though it will need to be a sort of their computed offsets.
3. Where do we sort keyframes whose offsets are not computable? They could be kept in their stable position ignoring offset or they could be effectively removed not appearing in getKeyframes.

For web animations, we never modify the passed in keyframes. They are returned in the order specified with specified offsets. We can't enforce the ordering requirement as strictly. We could do one of the following:
- Only require ordering of keyframes with overall percentage offsets, allow other keyframes in any order.
- Require ordering of keyframes within each named offset range. E.g. two keyframes on the `cover` range must be ordered with respect to each other. Though this gets more complicated when you consider that offsets will support calculations in the future.
I lean towards the first since calculations will also break the ability to ensure that order is correct when specified.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8507 using your GitHub account


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

Received on Tuesday, 28 February 2023 16:34:23 UTC