Skip to content

New Rule: no-unknown-animations #529

Open

Description

@Gaic4o

Rule details

I would like to propose a rule that warns when an animation name used in animation or animation-name does not have a matching @keyframes rule in the same source.

The rule would only check statically determinable animation names and ignore dynamic values such as var().

What type of rule is this?

Warns about a potential problem

Example code

.card {
    animation: fade-in 300ms ease;
}

.button {
    animation-name: slide-up;
}

@keyframes fade-out {
    from {
        opacity: 1;
    }

    to {
        opacity: 0;
    }
}

// In the example above, `fade-in` and `slide-up` are used as animation names, 
// but there are no matching `@keyframes` rules with those names defined in the same source,
// so I would expect the rule to report them.

Prior Art

Stylelint has a no-unknown-animations rule with the same purpose.

The rule checks animation names used in animation and animation-name, and treats @keyframes names defined in the same source or in files provided through referenceFiles as known animations.

Documentation: https://stylelint.io/user-guide/rules/no-unknown-animations/

Participation

  • I am willing to submit a pull request to implement this rule.

AI acknowledgment

  • I did not use AI to generate this issue report.
  • (If the above is not checked) I have reviewed the AI-generated content before submitting.

Additional comments

CSS can reference @keyframes rules defined in another stylesheet, so a missing @keyframes rule in the current source does not always mean the animation is undefined.

For this reason, I propose checking only animation names that can be determined statically and @keyframes rules defined in the same source for now.

I would appreciate feedback on whether this scope would be appropriate for @eslint/css, or whether cross-file cases should be handled differently.

Disclosure: I'm a participant of open source contribution program OSSCA

Activity

  1. moved this to Needs Triage in Triageon Aug 9, 2026
  2. moved this from Needs Triage to Feedback Needed in Triageon Aug 9, 2026
  3. DMartens commented on Aug 9, 2026

    @DMartens
    Contributor

    I agree that this would be a worthwile rule to add, but as this is a new rule we require additional team members to agree.
    Regarding checking cross-file:
    We currently also check only the current source file for custom properties in no-invalid-properties.

  4. nzakas commented on Aug 12, 2026

    @nzakas
    Member

    For compatibility with Stylelint, it seems like a good idea to add this.

    I need to spend some time thinking about how to make things work cross-file because that's where the real usefulness lies.

  5. added
    acceptedThere is consensus among the team that this change meets the criteria for inclusion
    on Aug 12, 2026
  6. moved this from Feedback Needed to Ready to Implement in Triageon Aug 12, 2026
  7. added a commit that references this issue on Aug 16, 2026
    c242e9b
  8. eslint-github-bot commented on Aug 16, 2026

    @eslint-github-bot

    👋 Hi! This issue is being addressed in pull request #535. Thanks, @Gaic4o!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

acceptedThere is consensus among the team that this change meets the criteria for inclusionfeature

Type

No type

Projects

  • Status
    Implementing

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions