[css-variables][css-syntax] Whitespace trimming and var() fallbacks

[andruud]

I'd like to clarify one detail regarding whitespace trimming defined by consume a declaration:

What is the computed value of --x here? --x: a var(--invalid, b );

I would interpret the current specs like this: the whitespace before a gets trimmed, but we don't remove any whitespace inside the value, so a var(--invalid, b ) (with no space in front) becomes the "parsed" value. Then, substitution-time, the var() reference resolves to its fallback _b_ (using _ for space), and the post-substitution value becomes a__b_. At this point it may make sense to behave as if relevant parts of "consume a declaration" had been invoked on the final post-substitution token sequence, trimming the result to a__b, although it's not really clear if this is expected.

OR, do we trim the spaces around the <declaration-value> of the fallback at some point instead (for example, "anything we substitute in gets trimmed first")? In that case, the computed value would be a_b.

@tabatkins @emilio

[emilio]

I think trimming around the fallback is what I implemented in Gecko and seems a potentially more desirable result since it's common to put whitespace after the fallback comma, afaict.

[tabatkins]

Yeah, it makes sense to trim around the fallback value. Happy to spec that.

[tabatkins]

Rather, <declaration-value> and <any-value> should probably trim whitespace around themselves. This'll be a no-op for custom properties themselves, since "parse a declaration" already does it, but it'll trim fallbacks and anywhere else that uses the productions.

[andruud]

Sounds good, as long as we make it clear exactly when this happens for custom properties, since that's a case of a <declaration-value> within a <declaration-value>.

For example, what happens if I use CSSOM to serialize the specified value of --x: var(--y,_b_)? ("_" being space).