[css-typed-om-1] Clarify reification of computed 1–4 side values

[janvarga]

There appears to be a gap around Typed OM reification of computed values for properties using 1–4 side patterns, such as:

• border-image-outset
• border-image-slice
• border-image-width

Consider:

document.body.attributeStyleMap.set("border-image-outset", new CSSUnitValue(0, "number"));
console.log(getComputedStyle(document.body).borderImageOutset);
console.log(document.body.computedStyleMap().get("border-image-outset"));

Current behavior (Chrome & Safari):

• CSSOM serialization:
  • getComputedStyle(...).borderImageOutset -> "0" or "auto"
• Typed OM:
  • computedStyleMap().get(...) -> CSSStyleValue {} (unsupported)

Current WPT coverage assumes these computed values are unsupported because the computed value conceptually expands to four values:

// Computed value is always four values, which are not supported in
// Typed OM level 1.

However, CSSOM serialization collapses equal computed sides to a shorter form, for example:

0 0 0 0 -> 0
1 2 1 2 -> 1 2

This raises the question whether Typed OM reification should follow:

• the conceptual computed value shape (always 4 values), or
• the canonical CSSOM serialization shape (collapsed representation)

Firefox's in-progress implementation will likely initially follow existing WPT coverage for compatibility (or relax WPT tests), but this behavior seems worth clarifying at the specification level.

Links:

• https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/border-image-outset.html
• https://github.com/web-platform-tests/wpt/blob/master/css/css-typed-om/the-stylepropertymap/properties/border-image-outset.html

[weinig]

I don't think the fact that the serialization coalesces really matters. Reification is defined as a specific set of steps defined for a property - https://drafts.css-houdini.org/css-typed-om/#reify-property. In this case, border-image-outset has no reification rules defined, (it's not even listed).

The comment in the WPT just seems misleading.

[janvarga]

Unfortunately the spec seems to be out of sync, see issue #13907

[janvarga]

Another example is cursor, which also has no property-specific reification rules defined in the specification. Despite that, there is existing WPT coverage:
https://github.com/web-platform-tests/wpt/blob/master/css/css-typed-om/the-stylepropertymap/properties/cursor.html

and browsers already implement/pass that behavior:
https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/cursor.html?label=experimental&label=master&aligned

When looking at runUnsupportedPropertyTests usage across these Typed OM property tests, there seems to be a pattern where values that cannot be represented as a single keyword/value (for example multi-keyword or multi-component values) are generally treated as unsupported and reified as CSSStyleValue. So it seems a similar approach could also make sense for these computed values.

[janvarga]

The comment in the WPT just seems misleading.

Note that the current WPT still expects specified values to reify into the corresponding Typed OM objects, while only computed values are expected to be treated as unsupported. So the current WPT behavior does not appear to fully match the specification.

[weinig]

Should we update WPT to match the spec?

[janvarga]

Should we update WPT to match the spec?

I don't think so, at least not as a general rule. There are quite a few cases where the Typed OM spec is out of sync with existing WPT coverage and interoperable browser behavior. In many of those cases the WPT behavior seems to reflect the direction implementations have converged on, while the spec still needs to be updated.

See also w3c/css-houdini-drafts#1159

[weinig]

I don't think so, at least not as a general rule

This is a surprising statement to me. I would have surely thought as a general rule WPT should match the specs.

My current plan for WebKit is to match the spec and update the tests to match as well.

[janvarga]

I don't think so, at least not as a general rule

This is a surprising statement to me. I would have surely thought as a general rule WPT should match the specs.

Yes, I agree that should generally be the case. The surprising part here is that this area of the Typed OM spec appears to be significantly out of sync with existing WPT coverage and browser behavior.

My current plan for WebKit is to match the spec and update the tests to match as well.

Could you discuss that with the spec editor and other implementors first? Firefox is currently close to matching the existing Chrome/Safari behavior for these property reification tests, and a broad WPT change here could invalidate a lot of recent implementation work.

There already seem to be many existing Typed OM WPT additions for properties that are either not listed in the spec’s Property-specific Rules section, or are listed without enough detail to define the tested behavior. For example:

• web-platform-tests/wpt@6ee4340 (anchor-scope is not listed in the spec)
• web-platform-tests/wpt@94e6098 (animation-duration and animation-iteration-count are not listed; gap is listed but without a clear reification definition; logical not listed; shape-margin listed but without a definition; stroke-dasharray listed but without a definition)

Those changes were also added by WebKit contributors, so it seems the current ecosystem has already been evolving based on interoperable implementation behavior and WPT convergence, even in areas where the spec text is incomplete. Because of that, I think it would be good to align on the broader direction before making large compatibility-impacting WPT changes.

[SebastianZ]

My current plan for WebKit is to match the spec and update the tests to match as well.

Could you discuss that with the spec editor and other implementors first? Firefox is currently close to matching the existing Chrome/Safari behavior for these property reification tests, and a broad WPT change here could invalidate a lot of recent implementation work.

@tabatkins @FremyCompany

[emilio]

I think it probably makes sense to, if we can't come up with general rules, spec the reification behavior along with the properties (in the property table).

I have a slight preference to discuss the path forward here before mass-changing WPT...

[weinig]

I am not optimistic that general rules will work all that well, mainly due to the relatively low semantic fidelity of the grammars, and the risk of subtle changes to a grammar causing a breaking change to reification.

Happy to hold off on updating the tests, but lacking movement on the spec, at some point, having WPT reflect the spec is the right choice. Having WPT testing something that is not spec compliant seems actively bad and I generally think we should be more aggressive in making them match.

[janvarga]

Thanks, we definitely appreciate holding off on updating the tests for now.

And I generally agree that WPT should ultimately reflect the specification. I think the tricky part in this particular case is that the synchronization probably needs to go both ways, not only updating WPT to match the current spec text, but also updating the spec based on existing WPT coverage and interoperable UA behavior in areas where multiple implementations have already converged and the spec is currently incomplete or out of sync.