-
Notifications
You must be signed in to change notification settings - Fork 693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cssom][css-variables] Whitespaces in serialization of custom property value and value with variable reference #881
Comments
cc @heycam |
Alternatively, to make the output nice, we can say in "serialize a CSS declaration" that, if the value doesn't have any preceding whitespace, than add a whitespace after colon, and if the value doesn't have any trailing whitespace, add a whitespace before "!important". That would change the value, but |
Or never output spaces for custom properties, so the value doesn't change and |
CSSWG f2f Seattle - resolved to keep syntax as is and for implementations to match the current impl of Firefox. |
Also value with variable reference, which is a sequence of tokens as well, just like value of custom properties. |
The Syntax spec elides information of how many and what types of whitespace characters were parsed; it just emits a whitespace token to represent a run of whitespace. Like with comments, you're allowed to remember exactly what the whitespace was, but you're not required to; you can serialize whitespace tokens out as a single space if you want. |
I believe the resolution in #774 overrides the resolution here, and I also agree that is better. |
As per w3c/csswg-drafts#881 and w3c/csswg-drafts#774. Differential Revision: https://phabricator.services.mozilla.com/D116459 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1713787 gecko-commit: d55d07d3e8ccfa9a6bd619e5a1863927e45d3aae gecko-reviewers: xidorn
As per w3c/csswg-drafts#881 and w3c/csswg-drafts#774. Differential Revision: https://phabricator.services.mozilla.com/D116459 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1713787 gecko-commit: d55d07d3e8ccfa9a6bd619e5a1863927e45d3aae gecko-reviewers: xidorn
As per w3c/csswg-drafts#881 and w3c/csswg-drafts#774. Differential Revision: https://phabricator.services.mozilla.com/D116459
As per w3c/csswg-drafts#881 and w3c/csswg-drafts#774. Differential Revision: https://phabricator.services.mozilla.com/D116459
As per w3c/csswg-drafts#881 and w3c/csswg-drafts#774. Differential Revision: https://phabricator.services.mozilla.com/D116459
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:
what should be the result of
rule.style.getPropertyValue('--a')
andrule.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 makecssText
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.The text was updated successfully, but these errors were encountered: