[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.

[tabatkins]

Given our existing disambiguation rules favoring an animation-name coming last (and the canonical order being written to support that), I don't think an option having animation-name coming first is possible actually.

We could still adopt @flackr's suggestion of the new longhands only being allowed after an unambiguous animation-name (that is, a keyword that's either not valid for any Animations 1 longhand, or one that is valid for a property but which has already had that property claim an earlier keyword, like in ease-in ease-out), but I feel like that's getting deep into the weeds of forcing authors to understand CSS parsing at a deep level. When possible we should make the parsing rules as natural and easy to understand as we can. (We're definitely stuck with a bad situation here regardless, but we should make it as painless as we can.)

This is why I favor some variety of optional prefix for the animation-name, and only allowing the Animations 2+ longhands if animation-name is written with this prefix.

We have a precedent for using the / for this kind of thing - a recent example being the color function syntax, but an older and probably more relevant example being the font shorthand, which uses a slash before the line-height component to distinguish it from the font-size component. There, the / <length> can be arbitrarily reordered in the property, with the only constraint being that it needs to be paired with a preceding font-size.

The other possibility is using a keyword prefix. This has the advantage of probably being what we'll need to accommodate more custom-idents, like the timeline phase name - it might get added to the shorthand as phase <custom-ident>. However, by definition it'll be longer than the slash, which is less ideal for a required component.

@fantasai pointed out in the call that this "prefix an ambiguous value with a disambiguating keyword" currently has only been used in functions; it hasn't shown up in a property value yet, so we should make sure it's what we want before we establish the precedent.

So, my suggestion is that we allow the animation-name component to be prefixed with a /, make future custom-idents (like timeline phase) prefixed with a keyword, and fork the syntax accordingly: if animation-name is written without the / we only allow the Animations 1 properties (treating newer properties as reset-only), but if it is written with a slash we allow the whole set. This will encourage authors to migrate to the slashed syntax. We should also define that the slash is emitted by the default serialization in all cases.

[SebastianZ]

Summarizing the suggestions for the syntax changes so far:

• Put the animation name first or last and use a slash to separate it from the rest of the longhands
• Allow to define the animation name as a <string>
• New property keywords will only be used if they are unambigiously not an animation name
• Add new name properties like animation-timeline with a prefix
• Animation name first, then the rest

Sebastian

[SebastianZ]

* Put the animation name first or last and use a slash to separate it from the rest of the longhands

That was the initial suggestion and also what I and obviously @tabatkins would prefer.

So, my suggestion is that we allow the animation-name component to be prefixed with a /, make future custom-idents (like timeline phase) prefixed with a keyword…

If we're going with prefixes, we still need to enforce the order somehow. Otherwise we'll have another potential name conflict. That time between the prefix keyword and the longhands keywords.

I'd actually separate future custom-idents with another slash instead. This avoids any conflicts of the longhand keywords. Though it would also always require to set the value for the animation name.

So it would be <animation-name> / <animation-timeline> / ….

* Allow to define the animation name as a `<string>`

One of my initial suggestions. It would clearly distinguish the name from the keywords, though given that we normally don't have names as strings probably not the best option. And it would still require a solution like above for future name-longhands.

* New property keywords will only be used if they are unambigiously _not_ an animation name

As Tab wrote, this makes it even more complicated for authors to match what's a name and what's a keyword.

* Add new name properties like `animation-timeline` with a prefix

See my point on this above.

* Animation name first, then the rest

As Tab wrote, this is not possible given that the name currently comes last when interpreting the values.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed [css-animations-2] Make animation shorthand syntax future-proof, and agreed to the following:

• RESOLVED: Add a new syntax for the animation shorthand where the animation-name comes first, followed by a slash, so that the new syntax (but not the old one) can accept animation-timeline and animation-composition in the shorthand. Work out further details in issue.

The full IRC log of that discussion

<dbaron> SebastianZ: There are multiple additions -- new longhands -- to animation. Starting to collide because data types are the same.
<dbaron> ... I was proposing to have a new syntax that avoids collisions.
<dbaron> ... collisions between those additions.
<dbaron> ... I had different proposals on how to solve that.
<dbaron> ... I think we already had a resolution to reset new properties that are added but if we want to add new ones to the shorthand we should discuss how to do that.
<dbaron> ... One proposal by me was to animation-name animation-timeline are colliding now.
<dbaron> flackr: Is there a proposal/
<dbaron> SebastianZ: Proposal is to change syntax or use a new syntax that avoids issues with additions to the shorthand.
<dbaron> ... so if we want to include animation-timeline in the shorthand, we have to find a way to do it so it doesn't collide with animation-name.
<flackr> q+
<dbaron> ... I don't remember what other longhand was added, but there was another one that collided with animation-name
<dbaron> ... So we have to find a way how to include them without any ambiguities.
<dbaron> ... my proposal was to add slashes between them.
<ydaniv> animation-range, maybe?
<astearns> ack flackr
<dbaron> flackr: We already have ambiguity with anything that specifies time values -- they're positional. It's an option but not a great option. Other option that's come up in the past was having functional notation like timeline(timeline-name), which I think makes it clearer what's going on.
<fremy> +1 to what flackr said
<TabAtkins> my earlier proposal was `animation-name / <all other stuff>`
<TabAtkins> and if you didn' thave the slash it reset all the new properties
<dbaron> astearns: Something we could do in general for shorthands that could have ambiguities is to decide whether we go with slashes or with bracketed named sections of the shortand value.
<dbaron> SebastianZ: ideally we'd find a solution that's broader than just the animation shorthand
<dbaron> SebastianZ: It could be something other than slashes like functions or something else.
<TabAtkins> q+
<astearns> ack dbaron
<TabAtkins> dbaron: two things
<TabAtkins> dbaron: generally pretty positive about functions
<TabAtkins> dbaron: also, one reason we ahve difficult here is animation-name property accepts arbitrary custom-idents, not --prefixed
<TabAtkins> dbaron: which we now decide is a bad practice
<TabAtkins> dbaron: if we followed current best practices we'd have required keyframes to establish --prefix names
<TabAtkins> SebastianZ: even with dashes there is collision with timeline names
<dbaron> SebastianZ: even with -- there would be collisions between name and timeline both having dashes
<dbaron> TabAtkins: Other mistake with animation -- custom idents should be positionally unambiguous. Custom ident should have been required to be first in the shorthand.
<dbaron> TabAtkins: It's usually what authors write anyway. That we have to serialize the animation name last for these weird parsing reasons looks weird.
<astearns> ack TabAtkins
<dbaron> TabAtkins: That's why my suggestion was ...
<TabAtkins> that's why my suggestion was for "name / other stuff", that way the name comes first, where it belongs
<fantasai> +1 that seems nice
<ydaniv> +1
<flackr> +1 name / other stuff seems good to unblock adding things
<dbaron> astearns: what will we do for adding animation-timeline to the shorthand?
<dbaron> TabAtkins: we need to decide on one of the ways
<dbaron> SebastianZ: proposals were (1) adding slashes (2) positional stuff or (3) adding functions
<dbaron> astearns: given we're already in a bad situation with animation-name that can be anywhere I think we're limited to functional
<fantasai> strongly in favor of 1)
<dbaron> TabAtkins: no,... we could have a grammar fork. If you do name/stuff you can write a timeline name, otherwise you can't express timeline name in the shorthand. So allof them are compatible.
<fremy> slash is very unclear
<fantasai> positional is hard
<dbaron> s/allof/all of/
<fantasai> and really dislike introducing functional notations for a shorthand, we don't do that anywhere else
<TabAtkins> we use / for positional separation in several properties
<TabAtkins> like it's not *great* but
<dbaron> fantasai: I think hard to remember order required for positional things. We generally try to allow reordering.
<fremy> q+
<dbaron> ... using functional notation just to work around a shorthand thing, we don't do anywhere. Not pleasant to type. We use slashes in a bunch of places for syntactic ambiguity.
<flackr> q+
<dbaron> ... It's not amazing working with syntax in that way... we have to serialize the older things as older things for compat, but you can express any past/future possibilites as input using the new less confusing syntax.
<dbaron> fremy: I want to disagree that we never use functions for that. We do quite often. We have counter() that takes a name. If you want to ??? you can use a counter() function.
<dbaron> fantasai: counter() functions are different, you're processing the counter name and returning the result. It's actually a function, not something to disambiguate.
<astearns> ack fremy
<dbaron> fantasai: ... tagging values with function names is not a CSS pattern.
<astearns> ack flackr
<dbaron> flackr: I'm good with / being used to remove challenges with animation-name. But this only allows us to add one name before we can add positional stuff again.
<fremy> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Functions#animation_functions
<dbaron> flackr: We'll have the problem that the first dashed-ident after the slash is the timeline name, and the next thing that needs a name will be the second one.
<TabAtkins> this is true, yeah
<dbaron> SebastianZ: I think there was another longhand discussed to add to the shorthand as well... I think we're already in that situation.
<TabAtkins> we could *also* use the "keyword prefix" approach for the timeline name
<Rossen_> q?
<dbaron> ... for 'animation'. I think animation-composition.
<TabAtkins> so you'd say `timeline <name>` in the shorthand
<TabAtkins> then that's extendable for the future
<dbaron> TabAtkins: If we want to future proof against adding more names, we could use a keyword prefix rather than a function wrapper. I think we have used this before. `timeline <name>`. That extends into the future.
<dbaron> TabAtkins: that extends into the future. We could add more names in the future with similar prefixes.
<dbaron> TabAtkins: We still have to solve the animation-name thing separately.
<fremy> q+
<dbaron> flackr: I wasn't specific that it should be functions, keyword prefixes are great too.
<SebastianZ> q+
<dbaron> astearns: timeline <name> without the slash means you could put the animation-name anywhere you wanted
<fantasai> dbaron: unless the animation-name is timeline
<dbaron> TabAtkins: The current prefix tagging is inside functional syntaxes, not in a toplevel property value.
<fantasai> fantasai: The current keyword tagging is only in function syntaxes, haven't used in property values so far
<astearns> ack fremy
<dbaron> fremy: I'm still reading the timeline thing ... the timeline property already accepts scroll() and view() functions.
<dbaron> fremy: Can we not fixed that one? animation-timeline takes a timeline() function and then you don't nee a timeline prefix because the animation-timeline property takes a function all the time.
<dbaron> fremy: not sure if this is already shipped
<dbaron> flackr: would be hard to change existing animation-timeline property to requre that, but could make it always show up that way in the shorthand
<dbaron> fantasai: But do you then put timeline(scroll(...)) in the shorthand?
<dbaron> flackr: I don't think so.
<dbaron> fantasai: It seems like the logical conclusion but it's really awful.
<dbaron> flackr: The idea that if you specify a name in the animation-timeline, it's implicitly timeline(<name>), the other values are just scroll() and view() functions.
<dbaron> astearns: You could put a name in the longhand, but if you want to specify it in the shorthand you'd need to wrap in a function -- that discontinuity is not great.
<astearns> ack SebastianZ
<dbaron> SebastianZ: I agree with fantasai that this would be something new.
<dbaron> ... we do have the scroll() and view() function but they just refer to something.
<dbaron> ... we still have the timeline name they are referring to.
<fantasai> note that the functional keyword disambiguator pattern tends to use prepositions so it'd be something like "on <timeline>" if we follow that pattern
<dbaron> ... Introducing a function that directly reflects the property would be something new to CSS.
<dbaron> SebastianZ: On the other hand, regarding / syntax, we are already saying this could lead to issues. I was just thinking about that again.
<dbaron> ... what if you want to set one of these longhand properties but not the other ones?
<dbaron> ... that would be a bit hard with the slashes
<dbaron> fantasai: what?
<dbaron> SebastianZ: the animation-composition is the other issue we have
<dbaron> SebastianZ: If you want to set animation-composition but not the animation-timeline
<dbaron> [some confusion]
<flackr> animation: foo / add; would be valid
<dbaron> fantasai: Going forward the new syntax would require the animation name first, and have to follow it with a slash, and then after that there's no animation-name so there's no name clashes.
<dbaron> fantasai: We just need to avoid conflicts between the keywords going forward.
<dbaron> fantasai: We try to minimize positional-ness within a shorthand.
<dbaron> fantasai: positional relationships are hard to remember
<dbaron> fantasai: going forward, put an effort into choosing kewyords that don't clash, then we don't run into ambiguity.
<dbaron> SebastianZ: animation-timeline only allows dashed idents?
<dbaron> fantasai: dashed idets and none?
<dbaron> fremy: and auto
<dbaron> SebastianZ: there could still be clashes between new keywords that get added?
<fantasai> TabAtkins: but that's the initial value
<dbaron> SebastianZ: so if we have a new animation-timleine keyword, and have animation-composition as well.
<fremy> `auto` is going to be very popular...
<dbaron> fantasai: We can try to avoid clashes. Making everyhing positional all the time, or wrapping everything in functions, is not friendly to authors.
<dbaron> astearns: I think we need to wrap up.
<dbaron> astearns: can we resolve on: allow animation-timeline into the shorthand by adding a / after the animation-name
<flackr> q+
<dbaron> astearns: if people aren't happy with that today, we could hash out more in the issues
<dbaron> SebastianZ: animation-timeline plus animation-composition
<dbaron> fantasai: yeah, all the new stuff
<dbaron> flackr: animation-timeline takes an auto value, conflicts with duration
<dbaron> flackr: It's already the case that we have some overlapping values and we choose them positionally.
<dbaron> flackr: auto is going to be ambiguous with duration
<astearns> ack dbaron
<dbaron> fantasai: Could say you can't specify auto in the shorthand, and if you ??/ drop it
<flackr> ack flackr
<fantasai> dbaron: other thing we do, but it's slightly more complicated in parsing
<fantasai> dbaron: you can buffer having an auto value
<fantasai> dbaron: see an auto value, say it can be a value for either of these two properties and keep looking
<fantasai> dbaron: assign auto for the one that isn't assigned
<fantasai> dbaron: by another keyword
<fantasai> dbaron: it's done in other places
<TabAtkins> list-style is the example we do today
<fantasai> dbaron: a little bit of a pain for implementers, but not too hard
<fantasai> dbaron: and is friendly to authors
<dbaron> (ntim asked about list style)
<dbaron> astearns: Can we add / to shorthand to accomodate new longhands ,and then hammer out details for things we discovered today?
<fantasai> sgtm
<dbaron> flackr: sounds good to me
<dbaron> RESOLVED: Add a new syntax for the animation shorthand where the animation-name comes first, followed by a slash, so that the new syntax (but not the old one) can accept animation-timeline and animation-composition in the shorthand. Work out further details in issue.
<myles> ScribeNick: myles
<fantasai> also +1 to dbaron's solution to 'auto'