Re: [csswg-drafts] [scroll-animations-1] CSSNumberish time values to represent types. (#7102)

> @birtles you were instrumental in the original PR where we shifted scroll-animations to use CSSNumberish, let me know if I've missed any reasons why we should use CSSNumberish or if you think we shouldn't.

Hi!

I'm afraid I haven't followed too closely the API update so I don't know what would be best. Flicking through the previous discussion about this, I think some of the concerns included:

- loss of information / round-tripping if APIs return percentages resolved to absolute values (perhaps the API has changed such that this is no longer an issue?)
- precision of specifying percentages (i.e. if percentages are specified as values in the range [0, 1] you are more likely run into floating-point issues, e.g. `0.2 + 0.4 === 0.6000000000000001` whereas `20 + 40 === 60`). That said, we already use fractions like this for keyframe offsets so I guess it's not an issue.


I think it's probably helpful to think about what we want to do with **(1)** percentage-based times and **(2)** absolute-time keyframes in the future and let that inform our decision.

For example, for **(1)** I think we will want to support group effects where we specify the length of the group (e.g. 1000ms) and then define child keyframe effects that take up, e.g. 50% of that duration, and have a start delay of 25% etc. We've seen requests for that.

In that case, even for a purely time-based animation, it seems we would want to be able to support percentage-based inputs, at least. Would that suggest we should support percentage-based outputs too?

For **(2)** we've had almost the opposite request: support keyframes with absolute offsets (i.e. time values instead of percentages). See #4907 which includes samples like:

```js
document.querySelector(".box").animate([
    { offset: "0s", opacity: 1 },
    { offset: "1s", opacity: 0 }
  ]); /* No duration needed */
```

Would supporting that suggest we will end up using `CSSNumberish` in at least _some_ places in the API anyway?

It's a tough issue! I can see how the pixel-based approach feels simpler and more intuitive in some cases at least, but I wonder if the `CSSNumberish` approach might be more inline with future directions we want to take the API?

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7102#issuecomment-1074835685 using your GitHub account


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

Received on Tuesday, 22 March 2022 07:43:14 UTC