[css-values] toggle() for shorthands is not forward compatible

[Loirooriol]

https://drafts.csswg.org/css-values/#funcdef-toggle

If toggle() is used on a shorthand property, it sets each of its longhands to a toggle() value with arguments corresponding to what the longhand would have received had each of the original toggle() arguments been the sole value of the shorthand.

Let's consider display: toggle(block, flow-root, inline).

Right now, display is a longhand property, so we have:

• block flow -> block flow-root
• block flow-root -> inline flow
• anything else -> block flow

But it seems likely that we will want to convert display into a shorthand. Then, the example will become

display-outside: toggle(block, block, inline);
display-inside: toggle(flow, flow-root, flow);

Due to short-circuiting, that's equivalent to

display-outside: block;
display-inside: toggle(flow, flow-root);

Which behaves like

• block flow -> block flow-root
• anything else -> block flow

[fantasai]

@mirisuzanne recently proposed using @container style queries to solve the use cases of toggle(), so maybe it makes sense to do that and drop toggle() entirely.

[Loirooriol]

If toggle() can be replaced with something else then it's fine, but this issue doesn't mean that it's unsalvageable.

I guess toggle() in a shorthand should set the longhands to a pending-toggle-resolution internal value, that would serialize as empty string and cascade as normally. At computed value time we would resolve that by taking the shorthand, and evaluating it to each of the values in toggle(). If all longhands would have the same computed value as the parent element, then it's a match. Then we pick the corresponding longhand component of the next toggle value.

[tabatkins]

Ah, that's a great example, and definitely demonstrates the current spec text as being somewhat broken.

I agree that leaning on the identical solution we have for variables is probably what we'd have to do.