[css-houdini-drafts] [css-typed-om] Can we avoid property-specific reification rules for most cases? (#1159)

AtkinsSJ has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [css-typed-om] Can we avoid property-specific reification rules for most cases? ==
Apologies if this has been discussed before. I could only find #732, which doesn't go into any details.

Currently, the spec for reification [lists every property individually](https://drafts.css-houdini.org/css-typed-om-1/#reify-property). I think this has a few issues:
1. CSS has a *large* number of properties, and needing to write spec prose for reifying every single one is a lot of work. It's currently missing prose for a lot of them, probably for this reason.
2. Over time new properties get added, and this list would therefore need to be extended too. This makes it an ongoing chore for someone to maintain, and currently the list is missing a number of properties. (eg, most `animation` properties)
3. Properties also get new values and these would need handling. For example, `min-content`/`max-content` are not handled for `width`.
4. Most of these descriptions are very repetitive and could be handled with a short set of general-purpose rules.

CSS being what it is, there are always going to be some exceptions that require bespoke logic, but for the majority of these, the rules could be very similar to what's in https://drafts.css-houdini.org/css-properties-values-api-1/#css-style-value-reification for computed values: "If the value contains an ASF, reify a list of component values; if the value is a keyword, reify as a keyword; if it's a length reify as a length; ...; otherwise reify as a CSSStyleValue."

From my perspective as an implementer, this means less code for us, and also less work for the spec authors. Especially, it's less *maintenance* work as new CSS properties and values get added over time. 

I'm in the process of implementing Typed-OM for Ladybird, and I decided early on to experiment with reifying types generically instead of following the per-property rules, because it meant getting things up and working sooner. And then if needed, it can be replaced with the spec's rules. So far, it's not caused any compatibility issues, at least according to the WPT tests. And it has the advantage that new properties and values *just work* without needing to implement reification rules for them.

(As a side note, I partly hope that streamlining the spec like this would help encourage Gecko to implement it. It's a great feature and it's sad to see it largely unused because one of the Big Three doesn't support it.)

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1159 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 14 October 2025 09:21:41 UTC