Do the CSSOM part of #866

[frivoal]

Asides from the edits already done in #866, @tabatkins mentioned that:

the remaining detail for how legacy shorthands work needs to show up in CSSOM, specifically in https://drafts.csswg.org/cssom/#serializing-css-values (or more precisely, probably in the definition of "preferred order").

This remains to be done.

[cdoublev]

I understand that fixing this issue may not be a priority but can I assume that it can be partially fixed in serialize a CSS declaration block (instead of serialize a CSS value, what seems to be a better seperation of concerns to ignore a legacy shorthand):

- 3. If `property` maps to one or more shorthand properties, let `shorthands` be an array of those shorthand properties, in preferred order.
+ 3. If `property` maps to one or more shorthand properties, let `shorthands` be an array of those shorthand properties, in preferred order, ignoring legacy shorthands.

Also, there are some cases discussed in #8014 that I would like to be clarified.

Assuming an hypothetical legacy shorthand shorthand with syntax a | b and its target longhand with syntax c | d, a bidirectionnal mapping from b to c, I would expect the following serializations:

// EDIT: the following case shoud not exist (`longhand` should accept `a` for back-compat)
style.shorthand = 'a'
style.shorthand; // 'a'
style.longhand;  // ''
style.cssText;   // 'shorthand: a;'

style.shorthand = 'b'
style.shorthand; // 'b'
style.longhand;  // 'c'
style.cssText;   // 'longhand: c;'

style.shorthand = 'c'
style.shorthand; // ''
style.longhand;  // ''
style.cssText;   // ''

style['--custom'] = 'a'
style.shorthand = 'var(--custom)'
style.shorthand; // 'var(--custom)'
style.longhand;  // 'var(--custom)'
style.cssText;   // 'shorthand: var(--custom);'
computedStyle.shorthand; // 'a'
computedStyle.longhand; // ''

style.longhand = 'c'
style.shorthand; // 'b'
style.longhand;  // 'c'
style.cssText;   // 'longhand: c;'

style.longhand = 'var(--custom)'
style.shorthand; // 'var(--custom)'
style.longhand;  // 'var(--custom)'
style.cssText;   // 'longhand: var(--custom);'

[Loirooriol]

style.shorthand = 'a'

See #7195 for this case

style.shorthand = 'var(--custom)'
style.longhand;  // 'var(--custom)'

No, because we could have --custom: b, then longhand will compute to c, and var(--custom) is a bad serialization since longhand: b is invalid.

style.longhand = 'var(--custom)'
style.shorthand; // 'var(--custom)'

Similarly, if --custom: c, then the shorthand will "compute" to shorthand: b, so var(--custom) is a bad serialization.

See https://drafts.csswg.org/css-variables-1/#variables-in-shorthands

if any of the component longhand properties for a given shorthand are pending-substitution values, or contain var() functions of their own that have not yet been substituted, the shorthand property must serialize to the empty string.

[cdoublev]

Thanks for the link. It makes sense that the target property should include the legacy value in its syntax for back compat. So the first case in my examples should not exist.

What would you expect in the following situation?

style['--custom] = 'b'
style.shorthand = var(--custom)
style['--custom] = 'c'
style.longhand; // ??

I am not very comfortable with of their own because it prevents serializing a shorthand when all its longhand have been independently declared with the same custom variable (and the same fallbacks, if any). But comparing custom variables for checking equality seems non-trivial. But I am not sure this is the reason of this restriction.

Anyway, I do not have a strong opinion on serializing the target longhand when the legacy shorthand is declared with var(), and you and other members of the CSSWG are way more experienced than me.

[Loirooriol]

First, note that to set --custom you actually need style.setProperty('--custom', 'b').

Then, var(--custom) is not known at specified-value time. So it doesn't matter if --custom is b, c or whatever: what will happen is that the longhand is set to a pending-substitution value, which serializes as the empty string.