[css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties?

@dbaron

#4431 requests to turn box-shadow into a shorthand. During the discussion of this change @dbaron mentioned that there is a general issue in handling list-valued longhand properties.
According to him and @emilio dealing with such values is complicated as the properties can have differently long lists. And this seems especially true for background-* longhands.

As @tabatkins summarized it, they'd prefer if the computed value lists would be aligned with the used value lists, i.e. expanded or truncated depending on the length of the length-controlling property.

Having a deeper look at that, I realized that there are currently differences in handling such properties across browser engines but also within one browser engine. E.g. in Blink, the computed value list length of background-size is controlled by the length of the list in background-image, while transition-duration's computed value is not bound to the one of transition-property and rather corresponds to the authored value. In Gecko, all the values correspond to the authored value.

Looking at the specifications, they seem to only clearly define the used values but the computed value is underdefined. CSS Backgrounds 3 defines how different lengths of authored values are handled and mentions that "the UA must calculate its used value by repeating the list of values until there are enough" (emphasizing by me). It doesn't seem to specify how computed values are actually generated. CSS Animations 1 refers to this specification as well as CSS Transitions 1 does. There might also be more specifications for such list-valued properties that need clarification.

This issue is meant to clarify how such linked list-valued properties should be handled. Maybe the definition for this handling should be moved to a central place (maybe in CSS Values?).

Sebastian

@dbaron

Added Agenda+ as @dbaron, @emilio, and @tabatkins already started the discussion on this in a previous call and it is required for making progress on #4431 and other linked list-valued properties.

Sebastian

For what it's worth, this also applies to fill-image and its related list-valued properties.

Sebastian

I think clarifying and having a central definition might be useful, but in general if there isn't any kind of specific computation specified the computed value mirrors the specified value, so I think per-spec that's what's required. Whether we want to change that is a different question that might be worth discussing.

The CSS Working Group just discussed [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties?.

The full IRC log of that discussion

<emeyer> Topic: [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties?
<emeyer> Github: https://github.com//issues/7164
<emeyer> TabAtkins: Issue 4431 asked to turn box-shadow into a shorthand. Very reasonable. Because it’s a list-valued property, we’d have to make all longhands the same. It was brought up by dbaron that whenever you have these groups of longhands and have to sync up all the values, it’s problematic for implementations.
<emeyer> …What exactly are the reasons, and to what degree should we be avoiding them? This touches on some things being proposed and probably coming, like Toggles. It would be good to know how careful we need to be.
<emeyer> dbaron: I’m most familiar with an implementation that no longer exists, so this may be questionable input, but my experience was that it was a LOT of code to implement these.
<emeyer> …Given that, it’s not a that strong a preference. It’s a case where you can get properties where 90% of the work is parsing, not implementation on the other end.
<lea> syncing up list-valued longhands is also a problem for authors. This does not match a human's mental model about this at all
<emeyer> TabAtkins: Do you recall if it was a particular type of syncing up, or if it was all equally hard.
<emeyer> dbaron: I think it was they were all equally difficult and yet things were sufficiently different that you couldn’t coalesce.
<emeyer> TabAtkins: We should get input from people working on extant rendering engines. Anyone on the call that knows about that?
<emeyer> astearns: Doesn’t sound like we have current implementation experience here on the call. Lea did mention a problem for authors.
<fremy> +1 leaverou
<emeyer> lea: When authors think about list-value properties, they think of each thing as a unit. They think, I want this image at this size in this place, and the syntax forces them to do things in a way they don’t think about it.
<emeyer> TabAtkins: Agreed.
<emeyer> lea: Right, this makes sense with single values.
<emeyer> TabAtkins: We’re asking if it’s okay to expand for things that are list values.
<emeyer> florian: When used with a single value on the list, it’s useful to break up. Authors can help by defining custom properties that define certain combinations.
<emeyer> TabAtkins: That’s partially true. Authors can work around the present situation, and that’s good. But forcing them to work around a lot when we could take that need away isn’t great.
<emeyer> …If we can avoid this being necessary in common cases, that would be great.
<emeyer> astearns: The issue is whether we’re going to more closely specify computed values of list values.
<emeyer> Sebastian: It’s not completely defined yet but most or all list-valued properties base their logic on the definition for background. So they’re just referring to that and still differ on implementation. Even within one engine.
<emeyer> astearns: The difference is something we need to address even if implementation difficulty is a problem. I’m wondering whether we can get to a resolution about that specific difference and then people can start implementation to give feedback on difficulty.
<emeyer> TabAtkins: I’d like to have an idea of the matrix of current possibilities.
<astearns> ack fantasai
<emeyer> fantasai: The main question is are the lists truncated or extended at compute time or use-value time? Specification says use-value. It was suggested this might be easier if compute time was used. The difference in behavior will affect inheriting, which most of these properties don’t do, and might affect result of getComputedStyle.
<emeyer> …I don’t think it would be a problem to switch over to say list-matching happens at computed value time, but don’t know if that would make implementation easier.
<emeyer> astearns: We need to clarify what the current implementations do, how difficult it would be to change, and what we’d like to do in general at computed value time. We should take it back to the issue.

@LeaVerou

I've created three fiddles now to check the current behavior of computed values again. One with longhand properties where the length-controlling properties have longer lists than the controlled ones, one with longhand properties where the length-controlling properties have shorter lists than the controlled ones, and one with shorthand properties.
Testing with those fiddles, my initial comment on that seems to be slightly incorrect because in Gecko background-* longhands are treated special when it comes to the computed value.

Tests

Here are my observations regarding the list lengths of computed and used values in tabular form. I don't have access to MacOS/Safari, so maybe someone else can check the test cases there.

Longhands with controlling property lists longer than controlled ones

https://jsfiddle.net/SebastianZ/wyupok0h/

	Chrome	Firefox
`background-size`	computed and used: repeated to match controlling property	computed and used: repeated to match controlling property
`transition-duration`	computed: as authored, used: repeated to match controlling property	computed: as authored, used: repeated to match controlling property
`animation-duration`	computed: as authored, used: repeated to match controlling property	computed: as authored, used: repeated to match controlling property

Longhands with controlling property lists shorter than controlled ones

https://jsfiddle.net/SebastianZ/bxj4y3ar/

	Chrome	Firefox
`background-size`	computed and used: truncated to match controlling property	computed: as authored, used: repeated to match controlling property
`transition-duration`	computed: as authored, used: truncated to match controlling property	computed: as authored, used: truncated to match controlling property
`animation-duration`	computed: as authored, used: truncated to match controlling property	computed: as authored, used: truncated to match controlling property

Shorthands with controlling property lists longer than controlled ones

https://jsfiddle.net/SebastianZ/wmeLxhtf/

	Chrome	Firefox
`background-size`	computed and used: padded with initial value to match controlling property	computed and used: padded with initial value to match controlling property
`transition-duration`	computed and used: padded with initial value to match controlling property	computed and used: padded with initial value to match controlling property
`animation-duration`	computed and used: padded with initial value to match controlling property	computed and used: padded with initial value to match controlling property

"Repeated" refers to the spec. text, which currently reads like this:

The lists are matched up from the first value: excess values at the end are not used. If a property doesn’t have enough comma-separated values to match the number of layers, the UA must calculate its used value by repeating the list of values until there are enough.

Summary of current behavior

Both Chromium and Gecko special-case the background-* longhands by repeating them for the computed value in case they are shorter than background-image. When background-image is shorter than the longhands, Chromium truncates the longhands while Gecko keeps them as authored.
All other list-valued longhands are kept as authored for the computed value in both engines.

What do we want?

@LeaVerou mentioned on the last call, from an author's perspective, it may be a little easier to understand what's happening if computed and used values were the same. That means, repeating when the controlling property list is longer and truncating if it is shorter. I agree with her on that.

@emilio, @tabatkins, @nt1m Could you please check back with your teams regarding the current implementations, the complications, and what would make implementations actually easier?

Sebastian

Better getComputedStyle() with backgroundBlendMode

Bug 1858833 [wpt PR 42518] - fix #42496. better getCS with background…

What should be the declared/computed value of a coordinating list shorthand property when the base property has more values than other properties in the group?

In the example below, if an implementation outputs foo 1s, bar and foo 1s, 1s, is it implicitly repeating values? Is this non-conforming?

el.style.animation = '1s'
el.style.animationName = 'foo, bar'
el.style.animation; // ?

el.style.animation = 'foo'
el.style.animationDuration = '1s, 1s'
el.style.animation; // ?

Firefox returns empty string when some property in the group has a different value length than the base property. (Chrome still truncates/repeats values.)

This seems easier because all coordinating list shorthand properties may not be able to omit any property in the group.

For what it's worth, there definitely exist web platform tests that test for the current Chromium/WebKit behavior that doesn't follow the spec (such as https://wpt.fyi/results/css/css-backgrounds/parsing/background-computed.html); I didn't immediately spot any tests that test for the behavior that's actually in the spec.

Bug 1858833 [wpt PR 42518] - fix #42496. better getCS with background…

We'll need updates for all the remaining tagged specs. Dropping css-backgrounds-3 in favor of css-backgrounds-4 because L3 is practically a REC already.

Given there are still a few substantial changes to CSS Backgrounds 3 like 433051c, I think this should be added to level 3. See also #10010 (comment).

Sebastian

For reference, there's also the related issue #418 dedicated to the background shorthand.

Sebastian

I'm closing this issue, as it seems all spec edits have gone in. #12791 is tracking the WPT changes that need to happen.

Navigation Menu

Repository navigation

[css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties? #7164

Tests

Longhands with controlling property lists longer than controlled ones

Longhands with controlling property lists shorter than controlled ones

Shorthands with controlling property lists longer than controlled ones

Summary of current behavior

What do we want?

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties? #7164

Description

Activity

SebastianZ commented on Apr 21, 2022

SebastianZ commented on Apr 21, 2022

fantasai commented on May 11, 2022

css-meeting-bot commented on May 11, 2022

SebastianZ commented on May 29, 2022

Tests

Longhands with controlling property lists longer than controlled ones

Longhands with controlling property lists shorter than controlled ones

Shorthands with controlling property lists longer than controlled ones

Summary of current behavior

What do we want?

16 remaining items

cdoublev commented on Feb 6, 2025

dbaron commented on Jul 2, 2025

SebastianZ commented on Nov 5, 2025

SebastianZ commented on Nov 6, 2025

tabatkins commented on May 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions