- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 May 2023 16:27:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[scroll-animations-1] Explicit `auto` for `animation-duration` in the `animation` shorthand.``, and agreed to the following: * `RESOLVED: accept "auto" as an animation-duration in the animation shorthand` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: scroll-driven animations, we want them to implicitly/automatically use auto duration, which matches their animation range<br> <TabAtkins> flackr: So this raises whether "auto" can be used in the animation shorthand.<br> <TabAtkins> flackr: Tab suggested this is implied by omission, but this makes it impossible to represent a non-zero delay (since duration has to exist before a delay).<br> <TabAtkins> flackr: So I suggest we do allow "auto" explicitly.<br> <TabAtkins> flackr: This is similar to other properties like background<br> <TabAtkins> dbaron: Are there any other things in the animation shorthand that take "auto"?<br> <miriam> ack dbaron<br> <TabAtkins> flackr: No, besides animation-name of course<br> <TabAtkins> fantasai: I think we discussed having delay potentially be auto<br> <TabAtkins> flackr: Right, no conflict because delay is already positionally unambiguous with duration<br> <TabAtkins> flackr: Only concern is if a non-time property takes auto<br> <TabAtkins> +1<br> <TabAtkins> proposed resolution: accept "auto" as an animation-duration in the animation shorthand<br> <TabAtkins> miriam: Objections?<br> <TabAtkins> RESOLVED: accept "auto" as an animation-duration in the animation shorthand<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8656#issuecomment-1551715376 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 May 2023 16:27:42 UTC