- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Nov 2022 15:41:08 +0000
- To: public-css-archive@w3.org
@andruud noted this would also be exposed in `getComputedStyle` since we wouldn't have determined it to be 0 yet. This raises the risk of having it be the initial value as usage of `getComputedStyle` is much higher. Typically, developers would usually be reading the duration of elements animations which have durations, but if they did `let duration = parseFloat(getComputedStyle(elem).duration)` this would result in NaN for `"auto"` instead of 0 from `"0s"` :(. Proposals: 1. We should definitely support specifying the `auto` value in css-animations for animation-duration. 2. I also think ergonomically it would be a much better initial value: * Time-based durations don't make sense for scroll linked animations and having to specify `auto` or a time value and rely on the [conversion from a time based animation to a progress based one](https://drafts.csswg.org/web-animations-2/#animations) is an awkward requirement, e.g. `animation: keyframes scroll()` should "just work". * It results in the same duration for time-based animations. If we decide that we have to keep `0s` as the initial value we could update the [conversion from a time based animation to a progress based one](https://drafts.csswg.org/web-animations-2/#animations) to effectively convert `0s` animations to 100% as well, but this feels a bit more surprising especially if combined with proportion based delays. @fantasai FYI -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1308954151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 November 2022 15:41:10 UTC