Back in #774 we resolved that normal CSS parsing removes leading/trailing whitespace from property values. This was visible in custom properties, which retain all tokens, including whitespace.
However, the CSSOM setProperty() algo wasn't updated properly to handle this. It calls into "parse a CSS values", which just invokes Syntax's "parse a list of component values", which doesn't do anything special about whitespace. (Normal stylesheet parsing ends up invoking Syntax's "consume a declaration" instead, which does the whitespace stripping.)
Agenda+ for a quick confirmation that CSSOM should be fixed here to match, stripping whitespace from declarations. (I'd either do so by adding a step to "parse a CSS value" that drops the leading/trailing whitespace tokens from the list, or by adding a new entry point to Syntax specifically for "parse a declaration value" that does the same thing, then replacing "parse a CSS value" with just a call to that algo.)
(Since all browsers already agree with this change, this might be good for an async agenda+, @astearns ?)
Here's a couple of tests for setting properties with leading/trailing whitespace and substituting them, in various combinations of stylesheet and script.
set and use vars in style
<!DOCTYPE html>
<body>
<style>
body {
--one-prefix: a;
--two-prefix: b;
--one-suffix:c ;
--two-suffix:d ;
--none:x;
--test1: var(--none);
--test2: var(--one-prefix);
--test3: var(--two-prefix);
--test4:var(--one-suffix);
--test5:var(--two-suffix);
--test6:var(--none)var(--one-prefix)var(--two-prefix)var(--one-suffix)var(--two-suffix)var(--none);
}
</style>
<script>
for(var i = 1; i <= 6; i++) {
w("|"+getComputedStyle(document.body).getPropertyValue("--test"+i)+"|");
}
</script>
set vars in script, use vars in style
<!DOCTYPE html>
<body>
<script>
var s = document.body.style;
s.setProperty("--one-prefix", " a");
s.setProperty("--two-prefix", " b");
s.setProperty("--one-suffix", "c ");
s.setProperty("--two-suffix", "d ");
s.setProperty("--none", "x");
</script>
<style>
body {
--test1: var(--none);
--test2: var(--one-prefix);
--test3: var(--two-prefix);
--test4:var(--one-suffix);
--test5:var(--two-suffix);
--test6:var(--none)var(--one-prefix)var(--two-prefix)var(--one-suffix)var(--two-suffix)var(--none);
}
</style>
<script>
for(var i = 1; i <= 6; i++) {
w("|"+getComputedStyle(document.body).getPropertyValue("--test"+i)+"|");
}
</script>
set and use vars in script
<!DOCTYPE html>
<body>
<script>
var s = document.body.style;
s.setProperty("--one-prefix", " a");
s.setProperty("--two-prefix", " b");
s.setProperty("--one-suffix", "c ");
s.setProperty("--two-suffix", "d ");
s.setProperty("--none", "x");
s.setProperty("--test1", "var(--none)");
s.setProperty("--test2", "var(--one-prefix)");
s.setProperty("--test3", "var(--two-prefix)");
s.setProperty("--test4", "var(--one-suffix)");
s.setProperty("--test5", "var(--two-suffix)");
s.setProperty("--test6", "var(--none)var(--one-prefix)var(--two-prefix)var(--one-suffix)var(--two-suffix)var(--none)");
for(var i = 1; i <= 6; i++) {
w("|"+getComputedStyle(document.body).getPropertyValue("--test"+i)+"|");
}
</script>
</script>
All browsers I tested (Chrome, Firefox, Safari) do indeed strip whitespace and serialize identically in all three testcases, meaning it'll be completely safe to update the CSSOM text to match.
(Firefox has a bug when serializing the final entry of each test; I suspect they're not trimming trailing whitespace early but instead doing it last-moment, and that's throwing off their "do we need a comment between these substitution results" logic).
Back in #774 we resolved that normal CSS parsing removes leading/trailing whitespace from property values. This was visible in custom properties, which retain all tokens, including whitespace.
However, the CSSOM
setProperty()algo wasn't updated properly to handle this. It calls into "parse a CSS values", which just invokes Syntax's "parse a list of component values", which doesn't do anything special about whitespace. (Normal stylesheet parsing ends up invoking Syntax's "consume a declaration" instead, which does the whitespace stripping.)Agenda+ for a quick confirmation that CSSOM should be fixed here to match, stripping whitespace from declarations. (I'd either do so by adding a step to "parse a CSS value" that drops the leading/trailing whitespace tokens from the list, or by adding a new entry point to Syntax specifically for "parse a declaration value" that does the same thing, then replacing "parse a CSS value" with just a call to that algo.)
(Since all browsers already agree with this change, this might be good for an async agenda+, @astearns ?)
Here's a couple of tests for setting properties with leading/trailing whitespace and substituting them, in various combinations of stylesheet and script.
set and use vars in style
set vars in script, use vars in style
set and use vars in script
All browsers I tested (Chrome, Firefox, Safari) do indeed strip whitespace and serialize identically in all three testcases, meaning it'll be completely safe to update the CSSOM text to match.
(Firefox has a bug when serializing the final entry of each test; I suspect they're not trimming trailing whitespace early but instead doing it last-moment, and that's throwing off their "do we need a comment between these substitution results" logic).