- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Mar 2022 16:44:27 +0000
- To: public-css-archive@w3.org
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> <fantasai> Subtopic: CSSNumberish Time values to represent types<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7102<br> <fantasai> flackr: Scroll-linked animations is the first animation feature we're animating that doesn't animate in terms of time values<br> <fantasai> flackr: takes a scroll position and ultimately turns it into progress in an animation<br> <fantasai> flackr: but animations APIs let you observe the time, e.g. .currentTime<br> <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> <fantasai> flackr: or just make it a double, and have the risk of mixing units<br> <fantasai> flackr: I've outlines the advantages and disadvantages of each approach<br> <fantasai> flackr: we know that using numbers for non-time values works, that is what we have implemented in Chrome<br> <TabAtkins> q+<br> <fantasai> flackr: we'd have to use CSSNumberish in order to use units, so as not to break existing content which uses doubles<br> <Rossen_> q?<br> <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> <fantasai> flackr: and we can define conversions, as we have done in current spec, for taking a time-based animation and ...<br> <fantasai> flackr: rather than using time units as pixels or percentages<br> <fantasai> TabAtkins: I agree with flackr, keeping the double for representing milliseconds is fine<br> <fantasai> TabAtkins: reasoable for handling that<br> <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> <fantasai> TabAtkins: so very in favor of accepting all length units here<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: it wouldn't be possible if using a single type mapping against the double<br> <fantasai> Rossen_: sounds reasonable<br> <TabAtkins> s/being able/being unable/<br> <fantasai> Rossen_: anyone here prefer keeping doubles?<br> <fantasai> Rossen_: Why were doubles used? Why didn't we use CSSNumberish?<br> <fantasai> flackr: Legacy. Animations were only in the time domain; I don't think numberic values existed when the API was defined<br> <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> <fantasai> fantasai: Wanted to ask if Birtles had an opinion<br> <fantasai> flackr: Birtles was reviewing all the changes in Web Animations 2 to make this change<br> <fantasai> flackr: so this is just checking with the rest of the WG<br> <fantasai> flackr: unless he changed opinion, expect he's on board<br> <fantasai> Rossen_: OK, we can take a resolution, and re-open if he has a problem<br> <fantasai> Rossen_: Didn't hear any objections, so let's resolved<br> <fantasai> flackr: Brian actually commented on the issue in favor<br> <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