- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Jun 2023 23:46:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-animations-2] Should the initial value for animation-duration be auto?`, and agreed to the following: * `RESOLVED: gCS of animation-duration on a time-based animation with a duration of auto returns 0sec for compat reasons` <details><summary>The full IRC log of that discussion</summary> <fantasai> -> https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1562390274<br> <dael> flackr: We allowed specifying animation-ductiona:auto and make it the initial value which matches web anim. API. Having computed style return auto breaks some libraries. It can't handle the NaN from parsing auto<br> <dael> flackr: Prop is to return the resolved duration. When you have default it's 0sec today. May be a time in the future<br> <dael> flackr: For scroll timelines, technically resolved value should be a % but we don't support those on animation-duration. We could but if we don't would have to return auto in that case<br> <dael> Rossen_: What happens when you round trip the auto?<br> <dael> flackr: Won't alter behavior because computes to same resolved value<br> <dael> flackr: Only risk of returning auto is if we want to change in future to % it's possible people would start relying on auto. It would be people relying on scroll driven animations<br> <dael> Rossen_: If % interoduces auto wouldn't be the same?<br> <dael> flackr: no, not that<br> <dael> Rossen_: Sounds like open to changes/additions decision. not preventing anything with auto. Or am I misunderstanding<br> <dael> flackr: This shows up in computed style. If we want to return % it could break people expecting auto. I don't think that would happen, usage will be low for a while since it's new<br> <dael> Rossen_: Opinions from the group?<br> <dael> flackr: Further clarify, we're returning auto right now because can't pass a % to animation-duration right now<br> <dael> Rossen_: So tomorrow we introduce % it will have breaking effect<br> <dael> flackr: Yep<br> <dael> Rossen_: This is the part I'm hung up on. Wanted to probe for other opinions<br> <dael> fantasai: One thing to think about is what do we want this to do in the future. Do we want it to return actual value of duration in general or do we want it to return something like computed value and this is a compat exception<br> <dael> flackr: Good point. Could see arguement it's 0sec for compat and auto is fine in the future<br> <dael> fantasai: Effected APIs are GCS and getComputedTiming?<br> <dael> flackr: computed timing on animation already returns 0sec. It's just gCS<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1575146984<br> <dael> fantasai: Not sure I understand this comment ^<br> <dael> flackr: This is the thing VueJS is using.<br> <dael> fantasai: Plan is to...getComputedTiming returns active duraction and actual thing. gCS will return 0sec for compat reasons and if at some point we have group effects where auto would result it will return auto<br> <dael> flackr: Sounds reasonable as just a compat thing. That makes me feel much better<br> <fantasai> s/result it/result in something else, it/<br> <dael> Rossen_: I'm sold as well. Other opinions? Objections?<br> <dael> Prop: gCS of animation-duration on a time-based animation with a duration of auto returns 0sec<br> <dael> for compat reasons<br> <dael> Rossen_: Obj?<br> <dael> RESOLVED: gCS of animation-duration on a time-based animation with a duration of auto returns 0sec for compat reasons<br> <fantasai> and this doesn't apply if it doesn't actually resolve to 0sec :)<br> <fantasai> (which in the future, it might not)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1581661556 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 June 2023 23:46:53 UTC