[css-syntax] Trim whitespace around declarations?

[tabatkins]

Right now, the Syntax spec is clear about what the value of a declaration is - it's all the tokens between the : and the ;. In particular, this includes any initial or final whitespace, which is pretty common in declarations like color: red; or in omitted-semicolon situations like:

.foo {
  color:red
}

When serializing non-custom properties, this whitespace doesn't matter; the property value has been parsed into a specialized data structure, and serialization just works off of that - it doesn't even attempt to preserve source whitespace. This means, for example, that you can be sure the first character of 'color' will be a non-whitespace char.

But the value of a custom property is the token list it parses as, so technically the initial/final whitespace is part of its value and should be serialized with it. Add to this the resolution at TPAC that custom properties should store their source representations so they can reserialize exactly as written (rather than, in some situations, serializing with extra comments inserted). On the other hand, this can result in unexpected whitespace in the serialization, as the initial/final whitespace isn't really considered to be "part of the value". (This is why I'm reporting it - one of the engineers on our team was writing some code with custom properties and got tripped up by this.)

So my question is: do we want to alter the "consume a declaration" algorithm to trim initial/final whitespace tokens? That dodges the resolution, as it won't be part of the value anymore. This will have zero effect on ordinary properties, just custom properties, and will likely bring custom property serialization slightly more in line with author expectations.

[FremyCompany]

+1

[tabatkins]

agenda+ for a yay/nay on this. I don't have a strong opinion either way.

[AmeliaBR]

How would this affect declarations of the form:

:root  { --my-var: ; }
.class { --my-var: }

…which currently is a valid CSS var consisting of a single whitespace token? Is it fine so long as the ; is there, but not in the second case?

The ability to create empty vars is useful when you are adding a variable to a list property:

background-image: var(--element-bg) linear-gradient(black, gray);
transform: var(--base-transform) rotate(45deg);

[tabatkins]

Those two are exactly equivalent - in the second, the declaration extends until it hits the }, so its value is also a single whitespace token in the current spec.

(There shouldn't be any difference between --foo: ; and --foo:;, but I think there technically is today, as <declaration-value> is defined to be a sequence of one or more tokens. I should add a ?.)

I'm not intending to make "empty vars" invalid, just to trim the representation of variables. Under this proposal, both of those would report the property's value as an empty string.

[LeaVerou]

Strong +1 for this. It's very much against author expectations that CSSOM methods return whitespace around a value and it means that --foo: bar and --foo:bar have different values, which could lead to a lot of bugs.

[css-meeting-bot]

The CSS Working Group just discussed [css-syntax] Trim whitespace around declarations?, and agreed to the following resolutions:

• RESOLVED: trim white space before / after property value in a declaration.

The full IRC log of that discussion

<astearns> topic: [css-syntax] Trim whitespace around declarations?
<astearns> github topic: [css-syntax] Trim whitespace around declarations?
<astearns> github topic: https://github.com//issues/774
<fantasai> TabAtkins: This has impact on what custom property values are
<fantasai> TabAtkins: Because custom properties capture tokens
<fantasai> TabAtkins: Currently the white space before first value token is preserved
<fantasai> TabAtkins: All of the normal properties serialize out from OM, so they get normalized white space output
<fantasai> TabAtkins: Some people brought up maybe we should trim the white space from beginning and end of a token stream
<fantasai> TabAtkins: This would be a tweak to the Syntax spec
<fantasai> TabAtkins: to throw away this white space
<fantasai> TabAtkins: No consequence for ordinary CSS, they will continue to parse and serialize as usual
<fantasai> TabAtkins: It may or may not have an observable difference on serializing a rule of a style sheet... I think they generally reserialize from internal structures
<gregwhitworth> basically this saves authors from writing trim() when manipulating custom props
<fantasai> TabAtkins: Would have desired difference on serialization of custom property value when ppl write with typical whitespace after colon
<fantasai> TabAtkins: Saves authors from writing trim(), right, and also from forgetting to write trim() because they never have to write that for any other property
<fantasai> leaverou: Is there any use case where you want the white space
<fantasai> TabAtkins: If you're embedding an esoteric language...
<fantasai> TabAtkins: If you're embedding another programming language into CSS you'll have consequences anyway
<fantasai> TabAtkins: Don't think any other issue
<fantasai> leaverou: So benefit to it, and not hurting any use case. So I'm hugely in favor.
<fantasai> leaverou: Every time I use OM for custom properties, have to use trim(), it's really annoying.
<ChrisL> +1 to trimming
<fantasai> astearns: Proposal to trim whitespace on either side of all declarations. In favor / opposed?
<fantasai> RESOLVED: trim white space before / after property value in a declaration.

[upsuper]

If we do this, we should also tweak CSSOM spec to add the whitespaces back during serialization.

[tabatkins]

That's already there, no? https://drafts.csswg.org/cssom/#serialize-a-css-declaration

(This change actually makes the CSSOM round-trip values properly, instead of adding a space to the front.)

[heycam]

(There shouldn't be any difference between --foo: ; and --foo:;, but I think there technically is today, as <declaration-value> is defined to be a sequence of one or more tokens. I should add a ?.)

I'm not intending to make "empty vars" invalid, just to trim the representation of variables. Under this proposal, both of those would report the property's value as an empty string.

@tabatkins the ? never got added to the definition of --* in CSS Variables 1, so --foo: ; and --foo:; are both invalid per spec currently. Did you intend to change that?

[heycam]

The note at https://drafts.csswg.org/css-variables-1/#syntax

Note: While must represent at least one token, that one token may be whitespace. This implies that --foo: ; is valid, and the corresponding var(--foo) call would have a single space as its substitution value, but --foo:; is invalid.

needs updating either way.

[prjnt]

Note that the change to the custom var grammar means that --foo: ; results in --foo having its initial value, thus making background-image: var(--foo) #gradient equivalent to background-image: var(--no-such-var) #gradient per “substitute a var()” rules.

So allowing substituting an empty sequence of tokens requires change to those rules [or perhaps change to the initial value].

Another consideration is that --foo: ; still violates the core grammar, which entails extra work in both spec and implementations.

However, do we absolutely need to allow custom vars to have an empty value? 'background-image' should be doable using a none layer, and 'transform' can of course be done with an identity transform. It's certainly believable that uses exist; I'm just saying that reverting adding the ‘?’ to custom var grammar is an easy option for now, and might be taken if no-one can for now think of a convincing use.

[tabatkins]

Why would it make it have its initial value? "Empty" is not the initial value (but the initial value does, unfortunately, serialize as empty).