[csswg-drafts] [css-animations-2] Make animation shorthand syntax future-proof (#6946)

SebastianZ has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-animations-2] Make animation shorthand syntax future-proof ==
Splitting this from the discussion in #6930.

The `animation` shorthand property has this note regarding the interpretation of its syntax:

> Note that order is also important within each animation definition for distinguishing `<keyframes-name>` values from other keywords. When parsing, keywords that are valid for properties other than `animation-name` whose values were not found earlier in the shorthand must be accepted for those properties rather than for `animation-name`. Furthermore, when serializing, default values of other properties must be output in at least the cases necessary to distinguish an `animation-name` that could be a value of another property, and may be output in additional cases.

So keywords are preferrably interpreted as values for longhand properties other than `animation-name`.

This comes with the big downside that no new keywords can be introduced without risking to break existing pages. This is, if a keyword is introduced that is currently used as a `<keyframes-name>` value, it will then be interpreted as the keyword for another longhand instead.

Therefore, I suggest to change the syntax of `animation` in a way that the `animation-name` value can always be clearly distinguished from the other values.

Two solutions that come to my mind are separating it by a slash or allowing to define it as a `<string>`.

Of course, the existing syntax still needs to be supported as well to avoid breaking the web. And the transition to a new one will take many years.
Though in order to allow extending the existing features or add new ones (like `animation-composition`) that are covered by the shorthand I believe this is a necessary change.

Sebastian

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6946 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 07:45:36 UTC