Open frivoal opened 6 years ago
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);'
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.
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.
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.
Asides from the edits already done in https://github.com/w3c/csswg-drafts/issues/866, @tabatkins mentioned that:
This remains to be done.