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

[SebastianZ]

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

[valtlai]

Maybe one could just prefix the animation name with a double dash -- (like a custom property).

This seems to work in browsers (latest Chrome, Firefox and Safari):

<style>
  @keyframes --move {
    to {
      transform: translateY(2em);
    }
  }

  p {
    animation: --move 1s alternate infinite;
  }
</style>

<p>👀</p>

As a data URI:

data:text/html,<style>@keyframes --move{to{transform:translateY(2em)}}p{animation:--move 1s alternate infinite}</style><p>&%23x1f440;</p>

And if I read the spec correctly, <custom-ident> is allowed to start with a double hyphen, even though MDN says otherwise. On the other hand, the CSS Validator returns parse errors, but is that a bug? Edit: The spec changed in 2014 allowing -- to start an ident.

[SebastianZ]

That's also a solution that would work without a spec. change. Though I'm afraid without new syntax the pressure to switch away from names that can clash with keywords isn't big enough.

Sebastian

[SebastianZ]

Given the implementation of animation-composition in Gecko lately and being blocked on adding it to the shorthand, I think this should be discussed on a call.

Sebastian

[fantasai]

Simplest solution to unblock is add it to the shorthand as a reset-only sub-property.

But agree that it would be useful to get this solved going forward.

[css-meeting-bot]

The CSS Working Group just discussed Make animation shorthand syntax future-proof.

The full IRC log of that discussion

<TabAtkins> Topic: Make animation shorthand syntax future-proof
<TabAtkins> github: https://github.com//issues/6946

[css-meeting-bot]

The CSS Working Group just discussed Make aniamtion shorthand syntax future-proof, and agreed to the following:

• RESOLVED: All animation longhands not defined in Animations 1 are defined as reset-only sub-properties, while we work on how to make them specifiable without ambiguity.

The full IRC log of that discussion

<TabAtkins> Topic: Make aniamtion shorthand syntax future-proof
<TabAtkins> github: https://github.com//issues/6946
<TabAtkins> seb: We have an issue with new animation-* properties, that animation-name makes problems in the shorthand
<TabAtkins> seb: You can't distinguish animation names from the keywords from the other properties
<TabAtkins> seb: So how do we make it so that new properties, like animation-composition, can make it into the shorthand?
<TabAtkins> seb: One way would be to create a new optional syntax that separates the name from the rest with a slash, or something
<flackr> q+
<TabAtkins> seb: This would be optional, we couldn't enforce it on current property values
<TabAtkins> seb: This would hopefully be a gradual replacement, like with the color function syntaxes.
<TabAtkins> q+
<astearns> ack flackr
<TabAtkins> flackr: I think another possibility is that, for new properties, they will only be used if they are unambiguously not the animation name (youv'e specified another property before them)
<TabAtkins> seb: So making the order more fixed?
<TabAtkins> flackr: Until an animatino-name is specified, assume that all keywords are from the current set, not the new set
<astearns> ack TabAtkins
<fantasai> TabAtkins: So we take the current set of keywords allowed in animation shorthand right now
<fantasai> TabAtkins: and until you see any keyword other than those, we only parse those as keywords
<fantasai> TabAtkins: anything else, including keywords from additional properties, assumed to be an animation name
<fantasai> TabAtkins: and as soon as we see an animation name, we start parsing the rest as other properties
<fantasai> TabAtkins: [gives example]
<fantasai> flackr: Correct
<TabAtkins> seb: Dunno if websites are already using animation names with the current keywords
<fantasai> Sebo: If authors are using these keywords now what happens?
<fantasai> TabAtkins: [missed]
<TabAtkins> flackr: ONe complication - with animation-timeline we've added another arbitrary name to the shorthand, potentially
<TabAtkins> flackr: So we might want a way to future-proof these other properties with arbitrary names
<fantasai> TabAtkins: for future arbitrary-name ones, we might need to add them with a prefix like "phase"
<fantasai> TabAtkins: but still have to handle animation-name today
<fantasai> TabAtkins: My suggestion was that I do actually like the slash syntax, assuming address future things in a specific ways
<fantasai> TabAtkins: I like animation-name being able to specify with a slash so unambiguous where it is
<astearns> ack dbaron
<TabAtkins> dbaron: Stricter alternative of what flackr suggested
<TabAtkins> dbaron: Maybe easier to explain
<TabAtkins> dbaron: We only extend the shorthand if animation-name is first
<TabAtkins> dbaron: So rather than having "these have to be after the name, these dont'"
<TabAtkins> dbaron: Maybe the stricter rule of animation-name is first, and then you can use the new stuff
<flackr> +1 sgtm
<TabAtkins> astearns: Does the current shorthand have position restrictions?
<TabAtkins> TabAtkins: No
<TabAtkins> dbaron: I think Tab's explanation isn't quite what it is, but my memory is pretty old now
<TabAtkins> astearns: So if someone today is using a composition shorthand as the animation name, and it's put last, would this change make that declaration invalid?
<Sebo> Just for reference, here's the syntax: https://drafts.csswg.org/css-animations/#typedef-single-animation
<TabAtkins> fantasai: The canonical order puts the name last, so there's probably author sheets doing that today, and also script-generated values
<TabAtkins> fantasai: I think we'll have to fork the syntax in some way
<TabAtkins> fantasai: Need more brainstorming
<astearns> s/using a composition shorthand/using animation-composition/
<TabAtkins> fantasai: And we'll need to accommodate more custom idents too, as flackr mentioned
<astearns> ack fantasai
<dbaron> Just one example of how things work today: `animation: ease-in ease-out` is an animation where ease-in is the timing function and ease-out is the animation-name.
<TabAtkins> fantasai: For now, we can treat animatino-composition as a reset-only property, so it's reset by the 'animation' but can't be set in there
<TabAtkins> fantasai: That'll work to unblock while we solve the issue.
<TabAtkins> +1
<TabAtkins> Right, the non-name proeprties get first dibs on keywords, and animation-name takes the first unclaimed one
<TabAtkins> seb: So I heard two suggestions - a slash, or putting the name first and other keywords afterward
<TabAtkins> astearns: Possibly `name foo` instead of slash too
<TabAtkins> fantasai: I think we need to explore the syntax space, but not on the call
<TabAtkins> fantasai: We haven't yet used these kind of keyword indicators in property syntax, only in functions, so this'll be a first time.
<TabAtkins> I'm currently future-proofing a toggle proeprty by doing a keyword prefix, actually
<TabAtkins> astearns: So suggestion is we mark animation-composition as a reset-only sub-property for now, and work on a syntax allowing it to be set
<TabAtkins> fantasai: All longhands not in Animations 1 treated as reset-only for now
<Sebo> +1
<TabAtkins> RESOLVED: All animation longhands not defined in Animations 1 are defined as reset-only sub-properties, while we work on how to make them specifiable without ambiguity.