[css-properties-values-api] Mass property registration by prefix

[LeaVerou]

(Note: Edited on Jul 24th, 2026 to focus on wildcard prefixes. Comma-separated syntax shortcut moved to #14225 )

The problem

It's common to register a number of properties that share the same prefix with the same descriptors.
When the properties are known in advance, and are relatively few, #14225 covers it.

However, when the set is mutable, large, and/or not known in advance, this gets really messy.

Examples

• Particularly egregious example.
• Real-world example.
• More in this Twitter thread
• Utility registered properties like --int-*, --length-* etc see tweet by @propjockey.
  @tabatkins said they think it is feasible.

Proposal

Support an optional single wildcard at the end of <custom-property-name>.

It would be mandatory to precede the wildcard by -, both to reduce the size of any Bloom filters used by implementations but also for author-facing reasons, to prevent uninentional matches.

With #14225 the 4000 lines of property registrations here remain 4000 lines, just lighter.
With this, they collapse to 1:

@property --i-* {
	syntax: "<number>";
	initial-value: 0;
	inherits: true;
}

Spec changes

https://drafts.css-houdini.org/css-properties-values-api/#at-property-rule

The production corresponds to this: it’s defined as any (a valid identifier that starts with two dashes), except -- itself, which is reserved for future use by CSS. Custom properties are solely for use by authors and users; CSS will never give them a meaning beyond what is presented here.

to:

The production is defined as:

<custom-property-name> = <dashed-ident> [ '-*']?

with the exception that it excludes -- itself, which is reserved for future use by CSS. Custom properties are solely for use by authors and users; CSS will never give them a meaning beyond what is presented here.

Alternatively, since <dashed-ident> does not permit *, I suppose we'd need to define a new token, e.g. <dashed-ident-glob> or <dashed-ident-pattern> or <dashed-ident-set>.

CSSOM changes

We could introduce conveniences later, but no CSSOM changes are needed for an MVP:

• CSS.registerProperty() could just accept these tokens under name
• CSSOM can represent these under a single CSSPropertyRule.

Challenges

Conflict resolution

In the same spirit as #14225, @property rules do not cascade. If multiple match, only one wins.

However, I think there is value in tweaking the "last one wins" rule:

1. Exact wins over wildcard, regardless of order
2. Between two prefix rules, the longest one wins, regardless of order
3. Otherwise, last one wins

This means this works as expected:

@property --icon-* {
	syntax: "<image>";
	inherits: true;
}

@property --icon-start, --icon-end {
	syntax: "<image>";
	inherits: false;
}

or this:

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

@property --size-rel-* {
	syntax: "<length-percentage>";
	inherits: true;
}

Other related issues

• [css-properties-values-api] Shorthand for custom property declaration #7523

[tabatkins]

The first one (multiple comma-separated names in the registration) we should definitely do, no question. Such an obvious improvement.

The second (wildcard registration) is something I support if it's feasible on implementations. No need to get fancy with the API, it'll just be a new name form; an <ident-token> followed by a "*" <delim-token>.

Your idea of combining them if multiple apply is interesting, but new to the API; currently each definition is independent, and will override each other if they collide names. I'd assumed we'd use longest-prefix-match semantics, so in your example --int-foo-1 would use the @property --int-foo-* block, but not the @property --int-* one.

[tabatkins]

Oh, but:

It should also be pretty easy to do, if it's just a parse time shortcut that is expanded into multiple rules for the CSSOM.

It shouldn't be expanded into multiple rules. We can either make the .name property an array now, hoping the compat is fine, or keep it a string that might be comma-delimited.

[SebastianZ]

make the .name property an array now, hoping the compat is fine, or keep it a string that might be comma-delimited.

Then it should probably also be renamed to names to indicate that it can hold multiple property names, if there are no compat issues.

Sebastian

[bramus]

Got sent a similar request via Twitter: https://twitter.com/LukyVJ/status/1627624292484542467

With @property shipping in browsers other than Chrome soon, and more people using it, I predict more similar requests in the near future.

[Crissov]

For at least 4 years now, everybody has agreed the syntax for @property should be :

@property <custom-property-name># {
  <declaration-list>
}

but in the current draft it still lacks that #.

[andruud]

There is another proposal here: #7523 (comment) (based on Tab's post immediately before):

@property {
  syntax: "<length>";
  inherits: false;
  initial-value: 2147483647px;
  --width: initial; /* 2147483647px */
  --height: initial; /* 2147483647px */
  --depth: 0px;
}

And/or we could imagine that a hypothetical initial() function is allowed here, to be able to express an initial value in terms of other initial values:

@property {
  syntax: "<length>";
  inherits: false;
  --one: 1px;
  --two: 2px;
  --width: initial(--one);
  --height: initial(--two);
  --foo: calc(initial(--one) + initial(--two));
}

That would require a novel concept of "computing" an initial value, but that should be possible as long as everything is computationally independent otherwise.

---

Mass registration with wildcards: so ... @property --int-* is basically something like a "selector" that "matches" custom property names on that form? I'm not sure if it's wise to bake that much (potentially expensive) complexity into the the computed value process. Hopefully we can consider other ways to solve the use-cases this would be needed for. For example, custom functions/if() could help for some of them?

[LeaVerou]

Mass registration with wildcards: so ... @property --int-* is basically something like a "selector" that "matches" custom property names on that form? I'm not sure if it's wise to bake that much (potentially expensive) complexity into the the computed value process. Hopefully we can consider other ways to solve the use-cases this would be needed for. For example, custom functions/if() could help for some of them?

I do think we should introduce features that eliminate the need for the hundreds of custom properties currently needed by design systems, and yes custom functions and if() will help tremendously, but I don't think we'd ever get it down to such small numbers where mass-registration won't be desirable. And there is a nice decoupling in being able to write

@property --foo-color-* {
	syntax: "<color>";
	initial-value: transparent;
	inherits: true;
}

rather than having to list every color design token in a centralized place.

[Loirooriol]

https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle

append to decls all the custom properties whose computed value for obj is not the guaranteed-invalid value.

How do you conciliate this with mass registration? With --foo-color-*, there would be an infinite amount of such properties.

[andruud]

We'd have to say that @property --foo-color-* doesn't actually count as those (infinitely many) properties existing, but instead just affects the computed value process for the actually-specified custom properties that match.