[csswg-drafts] [cssom][css-variables] Whitespaces in serialization of custom property value and value with variable reference

upsuper has just created a new issue for 

== [cssom][css-variables] Whitespaces in serialization of custom 
property value and value with variable reference ==
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 {
what should the result of `rule.style.getPropertyValue('--a')` and 

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 

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/881 using your GitHub 

Received on Wednesday, 11 January 2017 05:18:57 UTC