[css-variables] Custom properties should *not* serialize "exactly as specified"

[Loirooriol]

Consider this code:

var s = document.body.style;
s.setProperty("--a", "a(");
s.setProperty("--b", "b");

The spec says "Specified values of custom properties must be serialized exactly as specified by the author". That's what Blink does, but it's bad!

s.getPropertyValue("--a"); // "a("
s.getPropertyValue("--b"); // "b"
s.cssText; // "--a:a(; --b:b;"

s.cssText = s.cssText;

s.getPropertyValue("--a"); // "a(; --b:b;"
s.getPropertyValue("--b"); // ""
s.cssText; // "--a:a(; --b:b;;"

s.cssText = s.cssText;

s.getPropertyValue("--a"); // "a(; --b:b;;"
s.getPropertyValue("--b"); // ""
s.cssText; // "--a:a(; --b:b;;;"

s.cssText = s.cssText;

s.getPropertyValue("--a"); // "a(; --b:b;;;"
s.getPropertyValue("--b"); // ""
s.cssText; // "--a:a(; --b:b;;;;"

I think Firefox is better, since it round-trips:

s.getPropertyValue("--a"); // "a()"
s.getPropertyValue("--b"); // "b"
s.cssText; // "--a: a(); --b: b;"

s.cssText = s.cssText;

s.getPropertyValue("--a"); // "a()"
s.getPropertyValue("--b"); // "b"
s.cssText; // "--a: a(); --b: b;" 

[andruud]

Good one. I've never liked that behavior. It's the only thing that behaves like that, and what actually happens when things are substituted isn't clear either.

exactly as specified by the author". That's what Blink does

Sidenote: No, Blink serializes tokens. So it has both the problem in this issue, and also it does the normalization stuff 4.1. Serializing Custom Properties wants to avoid. (Yay.)

[tabatkins]

Yeah, we should close open constructs, since the parser doesn't see that the construct isn't properly ended in that case anyway.

The problem is that we do need to exactly preserve things like long strings of digits.

and what actually happens when things are substituted isn't clear either.

That actually is clear if you're following the spec - the substitution is done with tokens, not characters, and in this example the --a property contains a single <function-token>, so it'll substitute that. When you later serialize the substituted result you should get a(), since you can't tell whether or not the ending token was supplied to a function token.

(To what extent browsers exactly follow the spec here is, uh, up for discussion.)

[cdoublev]

Note that this also happens (even in Firefox) with an arbitrary substitution containing value:

style.margin = '1px calc(1px / var(--custom)'
style.padding = '1px'

style.margin;  // 1px calc(1px / var(--custom)
style.padding; // 1px
style.cssText; // margin: 1px calc(1px / var(--custom); padding: 1px;

style.cssText += ''

style.margin;  // 1px calc(1px / var(--custom); padding: 1px;
style.padding; // ''
style.cssText; // margin: 1px calc(1px / var(--custom); padding: 1px;;

Custom property values are clearly specified as substituted in as a list of tokens. Fallback values are presumably also a list of tokens, assuming consume a declaration implies consuming a list of component values (step 5) while parsing against the grammar, which produces a list of tokens for the fallback values.

And if the other parts of the consumed declaration value (containing an arbitrary substitution) are consumed as tokens instead of component values, this can make a difference as demonstrated above.

[cdoublev]

we should close open constructs

Not sure if "open constructs" encompass a trailing reverse solidus:

style.setProperty('--a', '\\')
style.setProperty('--b', '1')
style.cssText; // --a: \; --b: 1;

Could a tokenizer switch, like for <unicode-range-token>, do the trick?

  If decl’s name is a custom property name string,
- then set decl’s original text
- to the segment of the original source text string
- corresponding to the tokens of decl’s value.
+ then consume the value of a custom property
+ from the segment of the original source text string
+ corresponding to the tokens of decl’s value,
+ and set decl’s value to the result.

Consume the value of a custom property would invoke the tokenizer with close open constructs set to true and open constructs would be closed in the appropriate tokenizer algorithms.

Implementations could store the declaration value as a list of tokens or as their serialization.