[csswg-drafts] [pointer-animations-1] Pointer timeline ranges (#12507)

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

== [pointer-animations-1] Pointer timeline ranges ==
This issue presents a new named animation ranges defined in the [Pointer-driven animations spec](https://drafts.csswg.org/pointer-animations-1/#pointer-timelines-ranges), and builds on top of the concept of [Timeline Ranges](https://drafts.csswg.org/scroll-animations-1/#timeline-ranges) defined in scroll-animations-1, plus the concept of [Animation Range Centering](https://github.com/w3c/csswg-drafts/issues/12471).

-----------

Pointer-driven animations introduce new timeline ranges to allow control over the size of the active range, and the interpolation behavior of the timeline, when used together with animation range centering, i.e. the `animation-range-center` property. These ranges replace the named ranges introduced in Scroll-Driven Animations, with ranges that are more fitting and appropriate for Pointer-Driven Animations. 

The spec currently defines the following range names:

### `fill`

* 0% \- start padding edge of the element’s principal box.  
* 100% \- end padding edge of the element’s principal box.  
* If center is shifted, then interpolations between 0%-50% and 50%-100% are scaled up/down to fit these ranges.

#### Example
<img width="500" height="333" alt="Image" src="https://github.com/user-attachments/assets/6c6c4e08-b2bf-4ca7-9ff5-a26f00023a77" />

### `fit`

* Same size as `fill`  
* The 0% and 100% points are offset according to the value of the `animation-range-center` property, so that the point of 50% remains at the center of the range.

#### Example

<img width="576" height="361" alt="Image" src="https://github.com/user-attachments/assets/c3325122-b7ec-4be7-9c0e-83f7cb7eee81" />

### `cover`

* Largest possible range that **fully covers** the element’s principal box according to the value of `animation-range-center`.  
* The **farthest side** from any padding edge to the 50% point is used, and then that side is mirrored to the other side.

#### Example
<img width="668" height="387" alt="Image" src="https://github.com/user-attachments/assets/ff168436-f600-408b-85fe-5aacfb91dd7f" />

### `contain`

* Largest possible range that is **fully contained within** the element’s principal box according to the value of `animation-range-center`.  
* The **closest side** from any padding edge to the 50% point is used, and then that side is mirrored to the other side.
#### Example
<img width="516" height="348" alt="Image" src="https://github.com/user-attachments/assets/84f99b89-6510-4ea6-bf3b-a56d154d1241" />

--------

**Note:** It's imperative that ranges are first centered according to `animation-range-center`, and only then `-start` and `-end` ranges are applied to expand/contract the active range, as well as adjust interpolation (where necessary) between edges and the 50% progress point.

--------

## Proposal: 

I think we have 3 options here:

1. Accept the above ranges as specced.  
2. It seems to me that mixing different ranges together doesn't really make any sense, so we could improve this in 2 ways:   
   1. Allow a single range name for PDAs, so that we only have: `<range-name> || <range-start-offset> <range-end-offset>?`, and we figure out the longhands for that.  
   2. Split the above ranges into more basic start/end edges as: `farthest-side`, `closest-side`, and `fixed`. Then the above becomes:  
      - `cover -> farthest / farthest`.  
      - `contain -> closest / closest`.  
      - `fill` is sort of magical here since it allows automatic flipping between `farthest / closest` and `closest / farthest`, the idea is that the offsets are relative to the edges.
      - `fit` doesn't conform to these names \- in this range the edges of the range aren't fixed to the edges of the timeline, instead the distances are fixed and offsets are relative to them.

I think I'm leaning towards 2i. - Allowing a single range name for PDAs. IMO these effects usually have a notion of spatial symmetry to them, so splitting the range to start and end doesn't make much sense in the context of PDAs. On top of that, I think the suggested ranges cover well beyond all the use-cases I could find/imagine.


/cc @flackr @fantasai @bramus 

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


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

Received on Monday, 21 July 2025 15:01:37 UTC