[css-typed-om] Can we avoid property-specific reification rules for most cases?

[AtkinsSJ]

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. 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.)

[SebastianZ]

(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.)

@janvarga actually started implementing it recently. They are probably interested in this issue.

Sebastian

[janvarga]

Thanks for adding me to this issue!

In Gecko, we’re implementing Typed OM reification through a generic ToTyped trait that’s derived for most style value types. Right now this covers keyword values, which are reified automatically as CSSKeywordValue objects.

Work is in progress to extend this to numeric types, which will reify as CSSNumericValue, etc. and eventually to other categories such as colors and transforms. The derive system is designed so that most types can be handled automatically, while still allowing explicit impl ToTyped definitions for special or complex cases.

This approach already follows the “type-based reification” model you describe? The mapping is determined by value type rather than property name, so new properties generally require no additional reification code (only if there's no suitable value type).

Here are some links: https://searchfox.org/firefox-main/rev/644f0db17749554fe23a45b43e77e61f42acdfd9/servo/components/style_traits/values.rs#597 https://searchfox.org/firefox-main/rev/644f0db17749554fe23a45b43e77e61f42acdfd9/servo/components/style_derive/to_typed.rs#12 https://searchfox.org/firefox-main/rev/644f0db17749554fe23a45b43e77e61f42acdfd9/servo/components/style/properties/mod.rs#142

https://bugzilla.mozilla.org/show_bug.cgi?id=1991631

[emilio]

Yeah part of the trick here is that for some cases where we need property-specific behavior we have a separate type. But it's a Rust type, not a CSS type. My understanding is that @AtkinsSJ is asking about the later :)

[janvarga]

Yeah, there are many cases where a Rust type exists just for given property.

[AtkinsSJ]

@janvarga actually started implementing it recently.

🎉 Excellent!

This approach already follows the “type-based reification” model you describe? The mapping is determined by value type rather than property name, so new properties generally require no additional reification code (only if there's no suitable value type).

Yes, that sounds exactly like what I'm doing for Ladybird, just ours is C++ not Rust: Each of our internal StyleValue classes has a reify() method that returns a corresponding CSSStyleValue subclass (falling back to a direct CSSStyleValue if nothing else is defined).

I haven't yet hit any cases that do require property-specific rules, though I'm still fleshing things out.

[janvarga]

You might want to check this patch which is going to land soon: https://phabricator.services.mozilla.com/D268163 Especially those XXX comments.

Not sure, if you can get rid of the property specific rules completely.

BTW, when I was reading the spec first time, it was a bit confusing to see all the properties listed.

Maybe the spec should have rules for CSS types and then rules for some properties?

[AtkinsSJ]

Maybe the spec should have rules for CSS types and then rules for some properties?

Yeah that's the best option I think. There are always some edge cases, but it shouldn't be too many in comparison.

[SebastianZ]

@tabatkins @FremyCompany It looks like all commenters agree that the spec should be changed to base their reification rules on value types instead of property names and only add specific rules where needed.

Sebastian

[janvarga]

Actually, sections 5.6–5.8 (numeric, color, transform) already define type-based reification rules, but the coverage seems incomplete, so many properties still have bespoke text. At minimum, it’s a bit confusing when a property is explicitly listed in 5.1 but doesn’t have any accompanying reification text.

[AtkinsSJ]

If you're referring to "reify a color value" and similar algorithms, those are how to do it, but not when. For example, the color property is specced but doesn't call that algorithm:

color For both specified and computed values:

1. If the value is currentcolor, reify an identifier from the value and return the result.
2. Otherwise, reify as a CSSStyleValue and return the result.

(Nothing actually calls "reify a color value". Same for transform values, though at least WPT tests those and they are expected to be returned.)

[janvarga]

Right, agreed.

And honestly, I often have to double-check either WPT expectations or even look at how Chrome or WebKit handle a given property to understand what the intended reification behavior should be.

[SebastianZ]

(Nothing actually calls "reify a color value". Same for transform values, though at least WPT tests those and they are expected to be returned.)

And honestly, I often have to double-check either WPT expectations or even look at how Chrome or WebKit handle a given property to understand what the intended reification behavior should be.

That sounds like an obvious oversight in the spec. Given that the existing implementations and WPTs already expect a type-based reification, it seems uncontroversial to change the spec accordingly. @astearns Does a change like this need a resolution or can this be accepted by editor discretion?

Sebastian

[astearns]

@SebastianZ this can be editorial work. But I expect as the changes are made there will be some cases where changing the definitions will result in a change in specified behavior. Those should be called out with separate issues for resolving on those non-editorial changes.