[css-animations] Clarify properties that are not allowed in @keyframes rule

[hiikezoe]

https://drafts.csswg.org/css-animations-1/#keyframes
The current spec defines 'animation-' longhands other than animation-timing-function and properties with !important are not allowed in keyframes. In gecko, we also disallow all transition longhands, i.e. transition-property, transition-duration, etc. etc.

@dbaron told me on a gecko bug that the CSS WG agreed all transition properties are not allowed before, so the spec should clearly mention it.

[upsuper]

I don't think we disallow transition properties in @keyframes in Gecko currently.

[dbaron]

I'm not sure about this though -- somebody would need to find the minutes, or reconsider whether it's the right thing...

[hiikezoe]

Ok, my words was ambiguous there. Actually current Gecko doesn't disallow any properties in @Keyframes rues, IIUC. We omit those properties when we generate/update a CSS animation from keyframes.

[birtles]

What do you mean by not allowed?

transition-* properties are not animatable but is this issue more about what the CSSOM returns for keyframes rules?

[hiikezoe]

What I wanted in the spec is an equivalent section with "Processing a keyframes argument" in the web animation spec.
https://drafts.csswg.org/web-animations-1/#processing-a-keyframes-argument

[birtles]

For Keyframe objects we can just say to skip non-animatable properties but for @keyframes rules we need to allow animation-timing-function.

In the sentence:

The <declaration-list> inside of <keyframe-block> accepts any CSS property except those defined in this specification, but does accept the animation-timing-function property and interprets it specially.

I'm not sure what "accepts" means here (are such properties ignored silently? Do they generate errors? Are they available in the CSSOM?). However, I suspect we want to do what Gecko does here and parse such properties, expose them in the CSSOM, but simply not animate them. i.e. this is Issue 1 from the spec:

This specification needs to define how the value is determined from the keyframes, like the section on Application of transitions does for CSS Transitions.

That would allow, for example, polyfilling an animation that includes the display property (a non-animatable property).

We should also get all those animation types documented in CSS V&U. Perhaps that's something I can follow up on in July.

[AmeliaBR]

The current spec text in css-animations is very explicit, but probably isn't consistent with the current intention:

The <declaration-list> inside of <keyframe-block> accepts any CSS property except those defined in this specification, but does accept the animation-timing-function property and interprets it specially. None of the properties interact with the cascade (so using !important on them is invalid and will cause the property to be ignored).

The transition properties aren't defined in css-animations, so they wouldn't be covered by that rule.

It should probably be rewritten to focus on whether or not the property is animatable, as defined in CSS Transitions (factoring in the current definition of "animatable" as separate from "interpolate-able").

Regardless, Brian has a good point about CSSOM: for properties that aren't animatable/allowed in keyframes, should they be dropped by the parser, or should they be accepted by the parser but ignored as far as applying the animation?

The same section later says:

The <keyframe-block> contains properties and values. The properties defined by this specification are ignored in these rules, with the exception of animation-timing-function, the behavior of which is described below. In addition, properties qualified with !important are invalid and ignored.

Which seems to imply there is a difference between "ignored" declarations and "invalid and ignored" declarations.

[birtles]

It should probably be rewritten to focus on whether or not the property is animatable, as defined in CSS Transitions (factoring in the current definition of "animatable" as separate from "interpolate-able").

This is the part that needs to happen in V&U. That is, the long term plan is that every property has an "Animation type" field (currently still called "Animatable" in some specs) and the definition of that type links either to a common definition in V&U or to a local definition in that spec. The following properties, however, will have "Animation type: Not animatable":

• animation-* (and shorthand)
• transition-* (and shorthand)
• display

[frivoal]

From #2737

Basically, I need to edit V&U before I can fix the other specs but every time I've tried I've got stuck working out how to refactor V&U.

Can I help? I want to fix #2737, and am willing to help figuring out its dependencies. What do you think needs to be refactored about V&U? And by the way, wouldn't sort of thing work better in css-cascade instead?

[birtles]

I would love your help!

Originally @tabatkins suggested the definition of animation types could go in V&U and it certainly made sense to me at the time. I'm not sure I understand why css-cascade would be better.

The rough idea is that there are up to three procedures that make up a type's animation behavior:

• interpolation
• addition
• accumulation

These procedures are defined in the abstract in Web Animations: procedures for animating properties.

For most types, addition is identical to accumulation and in most cases spec authors should not have to concern themselves with the difference between these two procedures. Web Animations tries to define things such that accumulation defaults to being equivalent to addition and we should probably preserve that however we link these definitions together.

Likewise, addition doesn't make sense for many types so we should also have a sensible default for that so that in many cases all you need to define is interpolation (like Web Animations attempts to do).

Currently the definition of animation types is mostly found in CSS Transitions. The proposal is to take that and move it to V&U (or wherever is most appropriate) since it is used by CSS Transitions, CSS Animations, and Web Animations.

Web Animations also has a few definitions of animation types for a limited set of types. Most of that spec text, however, should just be dropped once we have something equivalent in V&U. I'm happy to help with that part.

When I tried to spec this in V&U I wasn't sure how to arrange it. For example, take the <number> type. It seemed awkward to extend that currently very brief little section with formulae like we have in Web Animations for animating real numbers.

In fact, it seemed like a lot of the sections would get a lot longer and I wasn't sure if it was better to create a new section for animation types and risk having them get out of sync or interrupt the definitions of these types with all this talk about animation.