[cssom] Don't use "applies to" to define getComputedStyle behavior

[AmeliaBR]

The definition of resolved values in CSSOM — which are used in getComputedStyle results — currently includes sets of properties where the resolved value switches between the used value and the computed value depending on whether "the property applies to the element or pseudo-element".

As discussed in #3414 (comment), this is problematic because "applies to" isn't strictly defined for many properties in a way that can be used in normative tests. And the conclusion of the group in that discussion is that it would be better to fix the resolved value definition than to make "applies to" in property definition boxes as strict as would be required.

Since the used vs computed behavior is about legacy compat, the first step could be to review current implementations more carefully. Then maybe we can find a better definition for when the result switches from one to the other.

[emilio]

Some interop bugs:

• https://bugs.webkit.org/show_bug.cgi?id=197814
• https://bugzilla.mozilla.org/show_bug.cgi?id=1527392

That's from a quick skim. I'll try to get engines to align here.

[emilio]

Another one: https://bugzilla.mozilla.org/show_bug.cgi?id=1550997

[emilio]

Another one: https://bugzilla.mozilla.org/show_bug.cgi?id=1551000

[emilio]

So for https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-height with that case the only thing left is to define when they're resolved and how.

In Gecko, the check is "The element has a CSS layout box, and either the computed value of display is not inline, or the element is a replaced element".

In WebKit / Blink the check is "The element has a layout box, and IsBox() returns true for that". I'm not sure what that means exactly, would need to dig. But I suspect there's more behavior differences for e.g., SVG elements with display different than inline or such. The Gecko behavior is very easy to spec of course, but I think the Blink behavior also makes sense, so want to understand it better.

@kojiishi or @mstensho, do you know what would be a good-ish definition of what LayoutObject::IsBox() means in Blink? I get it means everything that inherits from LayoutBox, but that's not something that I could conceivably put into a spec.

[kojiishi]

In WebKit / Blink the check is "The element has a layout box, and IsBox() returns true for that".

It means, for non-SVG, the element is not text nor an inline box (e.g., span). Atomic inlines (replaced elements and inline block) are IsBox() true, so that might be one difference.

For SVG, I'm not an expert, but generally using IsBox() for SVG objects is not recommended because it often returns unexpected values. For instance, it is false for SVGContainer but true for SVGText.

[emilio]

w3c/svgwg#349 is another issue, seems like Blink returns used values for <rect>, <foreignObject> and <image>...

[emilio]

https://chromium.googlesource.com/chromium/src/+/269ecd52bd4e0ec15a70924b089589f9bfe26ee0 is the commit that introduced that, for my own reference. cc @fsoder

[fsoder]

For SVG elements Blink essentially follows "applies to".

[emilio]

@fsoder Seems like other than Blink every engine uses "CSS layout box which isn't a replaced inline element", would you be open to revert that patch? What <svg> elements does width apply to?

[fsoder]

I suggested returning computed values in w3c/svgwg#349 - an issue that I filed in response to a bug report - which would indicate level of author interest.
<image>, <rect> and <foreignObject> are the relevant elements IIRC.

[AmeliaBR]

width and height are extended to certain SVG elements (without CSS boxes) in https://svgwg.org/svg2-draft/geometry.html#Sizing

If you're implementing support for those properties within an SVG layout context, then the properties apply to the element as far as computed/resolved styles are concerned. But maybe we should be stating that explicitly?

Can we modify an "applies to" line in a partial property definition box? (ping @tabatkins)

[emilio]

Sure but do we really want them to return the used value? I always thought of the resolved value thing as a whole as a compatibility issue, rather than a feature.

[AmeliaBR]

@emilio, see the discussion in w3c/svgwg#349. The general consensus was consistency of author expectations (as in https://crbug.com/772707). Most properties that accept a length convert it to px when retrieved from getComputedStyle().

But, the current behavior in Blink results in an inconsistency between width/height (resolved value is used value, AKA always px) and the other SVG geometry properties (resolved value is computed value).

For this issue, the question is: How can we define the legacy requirements for resolved value in a way that is independent of "applies to"? Only then can we talk about whether there are contexts where a property applies to an element, but there is no legacy requirement for returning used values in getComputedStyle.

[emilio]

Would people be fine if I updated the spec to say that the width and height used value are returned when:

• The element has a CSS layout box (thus no SVG layout), and...
• The element is not a non-replaced inline element.

I think that matches all of WebKit / Blink / Gecko, per all the comments here, modulo blink resolving these for these three svg elements.

[emilio]

Most properties that accept a length convert it to px when retrieved from getComputedStyle().

(Also this is not true, these properties are the exception, not the rule)

[emilio]

Oh, though according to that Chromium issue, safari does return used value here as well? :(

[emilio]

Ok, so safari doesn't return the used value (per testing in https://phabricator.services.mozilla.com/D35651). Firefox does return something similar to the used value if display is different than inline (and I consider this a bug).

So we probably still can decide what to do. I'd prefer to change the spec to say "The element has a CSS layout box (thus no SVG layout), and isn't a replaced inline box.", but we could also go for the Blink behavior and add the whitelist of svg elements for which we return the used value...