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

The CSS Working Group just discussed `CSSNumberish Time values to represent types`, and agreed to the following:

* `RESOLVED: Use CSSNumberish for "time" values in Web Animations API`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Subtopic: CSSNumberish Time values to represent types<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/7102<br>
&lt;fantasai> flackr: Scroll-linked animations is the first animation feature we're animating that doesn't animate in terms of time values<br>
&lt;fantasai> flackr: takes a scroll position and ultimately turns it into progress in an animation<br>
&lt;fantasai> flackr: but animations APIs let you observe the time, e.g. .currentTime<br>
&lt;fantasai> flackr: so question is whether we should reflect the type of the unit to make it clear to the developer that it's not a time<br>
&lt;fantasai> flackr: or just make it a double, and have the risk of mixing units<br>
&lt;fantasai> flackr: I've outlines the advantages and disadvantages of each approach<br>
&lt;fantasai> flackr: we know that using numbers for non-time values works, that is what we have implemented in Chrome<br>
&lt;TabAtkins> q+<br>
&lt;fantasai> flackr: we'd have to use CSSNumberish in order to use units, so as not to break existing content which uses doubles<br>
&lt;Rossen_> q?<br>
&lt;fantasai> flackr: My preference is CSSNumberish, since that gives us the flexibility to know when different types are being into the system, and raise errors if mixing types<br>
&lt;fantasai> flackr: and we can define conversions, as we have done in current spec, for taking a time-based animation and ...<br>
&lt;fantasai> flackr: rather than using time units as pixels or percentages<br>
&lt;fantasai> TabAtkins: I agree with flackr, keeping the double for representing milliseconds is fine<br>
&lt;fantasai> TabAtkins: reasoable for handling that<br>
&lt;fantasai> TabAtkins: Being able to distinguish the actual CSS types when there is not a clear and obvious answer, and being able to use different CSS units, is bad<br>
&lt;fantasai> TabAtkins: so very in favor of accepting all length units here<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;fantasai> TabAtkins: it wouldn't be possible if using a single type mapping against the double<br>
&lt;fantasai> Rossen_: sounds reasonable<br>
&lt;TabAtkins> s/being able/being unable/<br>
&lt;fantasai> Rossen_: anyone here prefer keeping doubles?<br>
&lt;fantasai> Rossen_: Why were doubles used? Why didn't we use CSSNumberish?<br>
&lt;fantasai> flackr: Legacy. Animations were only in the time domain; I don't think numberic values existed when the API was defined<br>
&lt;fantasai> Rossen_: Sounds like we have a well-articulated path forward, and didn't hear anyone pushing for keeping doubles, so calling for objections<br>
&lt;fantasai> fantasai: Wanted to ask if Birtles had an opinion<br>
&lt;fantasai> flackr: Birtles was reviewing all the changes in Web Animations 2 to make this change<br>
&lt;fantasai> flackr: so this is just checking with the rest of the WG<br>
&lt;fantasai> flackr: unless he changed opinion, expect he's on board<br>
&lt;fantasai> Rossen_: OK, we can take a resolution, and re-open if he has a problem<br>
&lt;fantasai> Rossen_: Didn't hear any objections, so let's resolved<br>
&lt;fantasai> flackr: Brian actually commented on the issue in favor<br>
&lt;fantasai> RESOLVED: Use CSSNumberish for "time" values in Web Animations API<br>
</details>


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


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

Received on Wednesday, 30 March 2022 16:44:29 UTC