It is currently not clear how whitespaces should be handled in serialization of value of custom property and value of normal property but with varible reference.

For example, if I have the following style rule:

div {
  --a:␣␣x␣␣y␣␣;
  display:␣␣var(--x)␣␣var(--y)␣␣;
}

what should be the result of rule.style.getPropertyValue('--a') and rule.style.display?

Currently, browsers don't agree on the same behavior.

Gecko preserves all whitespaces for both cases, so

• rule.style.getPropertyValue('--a') -> ␣␣x␣␣y␣␣
• rule.style.display -> ␣␣var(--x)␣␣var(--y)␣␣

Blink strips preceding whitespaces for normal property value, and collapses continuous whitespaces into one, so:

• rule.style.getPropertyValue('--a') -> ␣x␣y␣
• rule.style.display -> var(--x)␣var(--y)␣

Since they are both sequences of tokens, Blink's behavior looks inconsistent to itself. Given that we want to preserve whitespaces for value of custom properties, I suggest we state explicitly that preceding whitespaces of property value with variable reference should be preserved as well.

As of whether continuous whitespaces should be collapsed into one, I don't have strong opinion on. It seems to me collapsing them would add an unnecessary pass for us, I tend to not do that. But I'm open to collapsing behavior or making it unspecified explicitly.

Also note that, the serialization algoritm for "serialize a CSS declaration" also needs to adjust accordingly, because it currently unconditionally appends a whitespace after colon, and prepends a whitespace before !important, which would make cssText not idempotent when value includes preceding or trailing whitespaces. I propose that we don't add whitespaces if the value is a sequence of tokens.