[css-animations-2] Make animation shorthand syntax future-proof

Open
#6,946 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
css
Domain
frontend, web-dev

Research direction

Start by reading this issue together with the discussion in #6930 and the cited animation shorthand syntax note. Compare the proposed slash-separated and string-based alternatives, while checking that existing syntax remains supported; done requires an agreed future-proof syntax design rather than an implementation patch.

Written by the indexing model from the issue text.

Description

Closed Accepted by CSSWG Resolution css-animations-2 Needs Edits

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

Dominant language
Bikeshed
Stars
4.9k
Forks
816
Avg merge
2d 18h
Merged PRs (30d)
24

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from w3c/csswg-drafts

All issues in w3c/csswg-drafts

Similar issues

More Web Dev issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.