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

To attempt to summarize, this issue is about what type of value API's like `currentTime`, or the values in `getTiming` / `getComputedTiming` should return. Regardless of whether scroll linked animations return pixels or percentages, the question in this issue is whether they should be double or CSSNumericValue with the corresponding type (but fall back to double when that type is milliseconds for backwards compatibility). The [old web animations interface only supported double](https://drafts.csswg.org/web-animations-1/#the-animation-interface), but in preparation for ScrollTimeline we [updated these interfaces in web-animations-2 to return CSSNumberish](https://drafts.csswg.org/web-animations-2/#the-animation-interface).

The advantages of using double are:
* Ease of use - can be directly used in calculations
* Follows existing pattern of unit-less type for animation times in current APIs.
* No errors required as all numbers are assumed to be the same units.

The advantages of CSSNumberish are:
* Can fall back to double for backwards compatibility on time based animations.
* Avoids accidental mixing of types (e.g. anim1.currentTime = anim2.currentTime where types are not equal)
* Can support other types of time in the future (e.g. we may want a different type of timeline to use percentages / lengths)
* Allows sensible implicit conversion to [adapt a time based animation to a non-time based timeline](https://drafts.csswg.org/web-animations-2/#animations:~:text=The%20procedure%20for%20converting%20a%20is%20as%20follows).
* We will likely want to support CSSNumberish input anyways as @birtles mentioned above for offsets

I think a discussion would be really helpful to surface whether there are strong reasons for or against one or the other approach.

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


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

Received on Tuesday, 29 March 2022 00:12:30 UTC