W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2017

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

From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Jan 2017 05:18:51 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-200005746-1484111929-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:07 UTC