Rule Change: validate `@property` descriptors in `no-invalid-at-rules`

[electrohyun]

What rule do you want to change?

no-invalid-at-rules

What change do you want to make?

Generate more warnings

How do you think the change should be implemented?

A new default behavior

Example code

@property --size {
	syntax: "<length>";
	inherits: false;
	initial-value: red;
}

@property --theme {
	syntax: "<not-a-type-name>";
	inherits: false;
	initial-value: red;
}

What does the rule currently do for this code?

The rule does not report either example.

First example

The rule checks each value separately:

1. "<length>" is a string, so syntax passes.
2. red is a CSS value, so initial-value passes.
3. The rule does not check whether red matches <length>.

Second example

The rule handles it as follows:

1. "<not-a-type-name>" is a string, so syntax passes.
2. The rule does not check the syntax definition inside the string.

What will the rule do after it's changed?

The rule will perform two additional checks.

1. Check whether the value inside syntax is a valid registered custom property syntax definition.
2. Check whether a specified initial-value matches that syntax.

The first example will report red because a color does not match <length>.

The second example will report "<not-a-type-name>" because that type does not exist.

The rule should not report missing descriptors. In the current specification, all @property descriptors are optional:

• syntax defaults to "*".
• inherits defaults to true.
• initial-value defaults to the guaranteed-invalid value.

These examples should remain valid:

@property --anything {
	initial-value: red;
}

@property --size {
	syntax: "<length>";
}

Participation

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

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

There are existing implementations.

1. Stylelint syntax-string-no-invalid checks the syntax definition inside the string.
2. Biome noInvalidPropertyInitValue checks whether initial-value matches syntax.

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

[DMartens]

I agree that we should support checking both the type in syntax and whether initial matches that type.
While no-invalid-at-rules has specific behavior for @charset (which only checks the prelude), I think this should be a new rule (e.g. no-invalid-custom-property-registration).
I would like opinions on this from other team members.