[css-animations] How is a list of <easing-function> be handled when used for a keyframe specific animation-timing-function

How should animation-timing-function in the following be interpreted?

@keyframes bounce {
  from {
    top: 100px;
    animation-timing-function: ease-out, ease-in;
  }
}

The grammar of animation-timing-function allows for a comma-separated list of <easing-function> values, and that makes sense outside of @keyframes, as it is part of a coordinated value list. But when used inside of @keyframes, the list version doesn't seem correct.

I haven't been able to find anything in the spec that restricts the grammar down to a single value inside of @keyframes, and I couldn't find any WPT tests that test for this.

(The same question applies to animation-composition).

Currently this doesn't have any useful application. Did you try it?
I guess if there's an interop behavior we could spec it, but I'm assuming it's either truncated, or completely dropped - which IMO is more preferred.

The issue isn't one of usefulness, it's that I can't figure out if it is specified.

I disagree with the notion that if something is not currently interop an issue it should not be specified. That puts the burden on new implementations to reverse engineer existing implementations.

At least in WebKit, the current implementation will succeed at parse time, but fail at style building time, but this is happening pretty haphazardly (and I almost broke it by switching to using the specified grammar more generally).

My preference would be for this to fail at parse time by specifying that the grammar to use inside a keyframe rule does not allow for lists.

I disagree with the notion that if something is not currently interop an issue it should not be specified. That puts the burden on new implementations to reverse engineer existing implementations.

At least in WebKit, the current implementation will succeed at parse time, but fail at style building time, but this is happening pretty haphazardly (and I almost broke it by switching to using the specified grammar more generally).

My preference would be for this to fail at parse time by specifying that the grammar to use inside a keyframe rule does not allow for lists.

I think I've been misunderstood here, what I meant is that preferably this should be dropped at parse time.
Looks like it is not specified, and probably overlooked.
It's possible to specify to drop this at parse time, unless that becomes a compat issue, i.e. if there's an existing behavior that's not eventually dropping this property completely.

Ah, I totally agree with that.

I think it is pretty unlikely for there to be any compat issues here, so, for the time being assume there are not, a concrete proposal here would be:

Specify that when used in a keyframe rule, the animation-timing-function property has the grammar <easing-function>.
Specify that when used in a keyframe rule, the animation-composition property has the grammar <single-animation-composition>.

Are there any other animation properties that might need similar special casing for use in a keyframe rule?

The original spec was not well-written in this regard, but imo the behavior the spec should define here is that the animation-* properties are not allowed inside of keyframes, but some related animation-* descriptors (with different, singular syntax) are allowed, and change the behavior of the keyframe itself.

@tabatkins

That makes sense. Then, the spec would have descriptor definitions for the special animation-timing-function and animation-composite descriptors in addition to the property definitions they already have (like we have for font-family, property: https://drafts.csswg.org/css-fonts-4/#propdef-font-family, @font-face descriptor: https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-family.

@tabatkins one question of bikeshed syntax I have is what is the correct For value for a case like this?

	<pre class='descdef'>
	Name: animation-timing-function
	Value: <<easing-function>>
	For: @keyframes
	Initial: N/A
	</pre>

Is @keyframes right even though these are always nested inside a specific sub-keyframe rule?

Not sure it actually makes any difference, as it can be clear in prose where it is legal, but if there is existing precedent, would be good to follow it.

Yeah, @keyframes is fine. The for doesn't specify some strict relationship, it's just a namespacing mechanism.

@astearns

@astearns I think we can async-resolve this one, looks like we're in agreement here that only a minor spec fix is needed.

Could someone summarize the minor fix?

@tabatkins

I think we can use @tabatkins's text as the proposal (*with small edits by me):

Fix spec to say animation-* properties are not allowed inside of keyframes, but some related animation-* descriptors with singular syntax are allowed, and change the behavior of the keyframe itself.

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Define animation-* descriptors with syntax subsets for use in @keyframes

I agree with the discussion here, but the proposed resolution is very vague. Let's go with ydaniv's wording. :)

Proposed Resolution: Fix spec to say animation-* properties are not allowed inside of keyframes, but corresponding animation-* descriptors with singular syntax are allowed, and change the behavior of the keyframe itself.

I try to come up with a proposed async resolution that fits into an email subject line. I did add more details in the body of the www-style email and linked back here.

I have two minor concerns about defining these animation-* properties accepted in keyframe rules, as descriptors for @keyframes.

(1) This should be updated (CSS Syntax):

Declarations are further categorized as property declarations or descriptor declarations, with the former setting CSS properties and appearing most often in qualified rules and the latter setting CSS descriptors, which appear only in at-rules.

Perhaps property declarations apply to elements, while descriptor declarations apply to the resource represented by the rule?

(2) And I think any author would expect @keyframes { animation-timing-function: ease } to be valid, given this:

Name: animation-timing-function
For: @keyframes

If For is merely a namespacing mechanisme, I do not see the point of exposing it.

(2) And I think any author would expect @keyframes { animation-timing-function: ease } to be valid, given this:

Name: animation-timing-function
For: @keyframes

If For is merely a namespacing mechanisme, I do not see the point of exposing it.

Alternatively, we could add a definition for nested scope and use that. For example, we could have something like this text somewhere:

"@keyframes rules use a nested scope for each individual keyframe. Though they are not introduced with an @ name, they are referenced in this specification as "{some-name-for-the-individual-keyframe-scope}"."

Navigation Menu

Repository navigation

[css-animations] How is a list of <easing-function> be handled when used for a keyframe specific animation-timing-function #14096

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-animations] How is a list of <easing-function> be handled when used for a keyframe specific animation-timing-function #14096

Description

Activity

ydaniv commented on Jun 28, 2026

weinig commented on Jun 29, 2026

ydaniv commented on Jun 29, 2026

weinig commented on Jun 29, 2026

tabatkins commented on Jun 29, 2026

weinig commented on Jun 30, 2026

tabatkins commented on Jun 30, 2026

ydaniv commented on Sep 23, 2026

astearns commented on Sep 23, 2026

ydaniv commented on Sep 25, 2026

astearns commented on Sep 28, 2026

fantasai commented on Sep 28, 2026

astearns commented on Sep 28, 2026

cdoublev commented on Sep 29, 2026

weinig commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions