- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jan 2022 01:42:10 +0000
- To: public-css-archive@w3.org
I'd rather not risk Web compat breakage with this, even if we have statistics that suggest no one currently uses "replace", "accumulate" or "add" as keyframes names. ("add" seems pretty likely at any rate.)
Partly because I'm not confident we could get comprehensive statistics (and _any_ breakage is pretty annoying for authors here) but partly because I guess we're going to encounter the same situation if we ever try to add new keywords for `animation-fill-mode`, `animation-play-state`, `animation-direction`, or `animation-timing-function` in future. That seems very likely to me—especially for new timing function keywords—so we should probably work out how to fix this in general.
> This will change the meaning of declarations like `animation: 1s replace`. Are we OK with that, or should we add some (potentially confusing) special parsing logic to make replace/add/accumulate match against the `<keyframes-name>` first?
I'm not sure I totally follow this suggestion but I think something like this is probably best.
The trouble, as I understand it, is if you have `animation: 1s replace add`, normally that would mean `animation-composition: replace` with `animation-name: add` but in this case it would be the reverse.
It would be nice if we can somehow continue to tell authors / tools to always put the animation-name last. Is it even possible to have a rule that lets `animation: 1s replace` give us `animation-name: replace` while `animation: 1s replace add` gives us `animation-name: add`?
--
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/6930#issuecomment-1011649484 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 January 2022 01:42:12 UTC