[cssom] Number of layers in getComputedStyle results

[ewilligers]

From Web Platform Tests issue (web-platform-tests/wpt#17925)

In background-blend-mode and most of the other background-* properties, Firefox has the number of layers in the getComputedStyle result matching the number of layers in the specified value (test). Blink and WebKit have the number of layers in the getComputedStyle result matching the number of layers in background-image (tests).

Which is expected?

[AmeliaBR]

It's not a special case where resolved value should be the used value. So I would expect getComputedStyle to return the computed value, which would have as many entries as specified since there's nothing in CSS Backgrounds that says otherwise. (And making the actual computed values match the background-image list length could mean losing information that should be available for inheritance.)

But, I'm not sure what should happen with a background shorthand from gCS if the style was originally set with longhands.

[emilio]

It's not a special case where resolved value should be the used value. So I would expect getComputedStyle to return the computed value, which would have as many entries as specified since there's nothing in CSS Backgrounds that says otherwise. (And making the actual computed values match the background-image list length could mean losing information that should be available for inheritance.)

I totally agree with this (and thus think Gecko is right in this case).

Furthermore I'd argue that similar properties like animations or transitions already work that way everywhere, so I think this is just a Blink / WebKit bug.

But, I'm not sure what should happen with a background shorthand from gCS if the style was originally set with longhands.

When the values cannot be appropriately represented as a shorthand, it should return the empty string, that's what every other property does.

[AmeliaBR]

When the values cannot be appropriately represented as a shorthand,

But in this case they could be represented as a shorthand, by adding extra "none" layers for background-image. But I'm not sure if that's consistent with the rest of the logic of layered backgrounds.

[fantasai]

Agenda+ because @emilio wanted a broader discussion of the issue. Personally agree with @AmeliaBR and @emilio's logic on what the result should be.

[Loirooriol]

And making the actual computed values match the background-image list length could mean losing information that should be available for inheritance.

This is precisely what's happening in Chromium, it's not just that getComputedStyle doesn't include all the information, it's also missing in the actual computed value: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/7696

[css-meeting-bot]

The CSS Working Group just discussed Number of layers in getComputedStyle results, and agreed to the following:

• RESOLVED: Have the computed value of the background / image layer properties match the number of items in the specified value
• RESOLVED: Apply the rule for computed value list length of background properties to all other similar list repeating properties like masking, transitions, animations.

The full IRC log of that discussion

<heycam> Topic: Number of layers in getComputedStyle results
<heycam> github: https://github.com//issues/4135
<heycam> fantasai: there's some inconsistency in how many layers we put in these properties
<heycam> ... the suggestion is to take the computed value's list length
<heycam> ... if you have a long list for background-image, but a short list for background-position
<heycam> ... when you return getCS, do you use the original list length, or the number of images?
<heycam> ... I think we should use the number of values specified
<heycam> oriol: in Chromium, this information is lost in the computed style
<heycam> ... inheriting onto children, the information is not inherited
<heycam> TabAtkins: this is a Chrome bug
<heycam> ... we should do the right thing and match Firefox here
<heycam> fantasai: let's do that, and clarify the Backgrounds spec
<heycam> ... which just says list, not how many items
<fantasai> file:///home/fantasai/w3c/csswg/css-backgrounds-3/Overview.html#background-repeat
<heycam> ... so clarify to the specified number of items
<fantasai> Computed value: list, each item a pair of keywords, one per dimension
<fantasai> list -> "list of the specified number of items"
<fantasai> or something
<fantasai> list (of the number of items specified)
<heycam> RESOLVED: Have the computed value of the background / image layer properties match the number of items in the specified value
<heycam> dbaron: other properties? transitions
<heycam> ... all of these cases are repeated lists where you key off one list to determine what happens
<fantasai> s/value/value of the property itself, not the reference property/
<heycam> ... but I think in all cases that is the right thing
<heycam> dbaron: transitions used to have two different types of list repeating
<heycam> TabAtkins: that's in V&U now
<fantasai> Not in Values. Values just as hhttps://drafts.csswg.org/css-values-4/#combining-values
<fantasai> https://drafts.csswg.org/web-animations-1/#animating-properties
<heycam> dbaron: backgrounds, masking, transitions, animations
<heycam> ... sounds like the relevant list here
<fantasai> ACTION: fantasai fix animation types of CSS Backgrounds
<heycam> RESOLVED: Apply the rule for computed value list length of background properties to all other similar list repeating properties like masking, transitions, animations.