[css-syntax-3]: Voluntary semicolons

[timreichen]

Allow semicolon to be voluntary after a Declaration when followed by newline or block closing.

let

div {
  background: red
  color: green
}

behave the same as

div {
  background: red;
  color: green;
}

link to the spec section:
https://www.w3.org/TR/css-syntax-3/#typedef-semicolon-token

Related links
https://teamtreehouse.com/community/does-the-semicolon-have-to-be-added-after-each-declaration-in-a-rule-or-is-it-optional (2017)

I can imagine that I am not the first one to raise an issue/proposal on that feature. But I could not find any. Links to issues and sources are welcome.

[tabatkins]

This would be a significant syntax change, and would introduce us to all the wonders and horrors of Javascript's ASI feature. It would make formatting values across multiple lines (useful for larger declarations, like multiple background layers, or the grid-template shorthand) fraught and complicated.

Given that we've dodged the bullet on ASI for several decades so far, I'm very strongly against any attempt to introduce it.

[tabatkins]

@timreichen I'm rejecting your proposal, but please let me know if you're okay with that, or if you feel strongly that we should reconsider.

[timreichen]

I think we should reconsider because this proposal has multiple aspects to consider:

• Simplicity
  I was always a fan of simplicity for users. If a parser can figure it out by itself without big impact, then let the parser do it.
• Native
  In my experience lots of people use transpilers (less, sass, scss, stylus etc.) to basically polyfill featues that lack in css. This is such a case. This along with proposals like nesting will make css more usable natively instead of using a transpiler.
• for aesthetics
  Code without semicolons look better imo. But since the omission is voluntary, no damage is done to anybody and it gives users more control over their code.
• More in alignment with javascript
  Since JS allowed the omission for its code, I struck me weird that css requires them. This will make the web standard more aligned to each other.

I agree there has to be a good solution about multiline declarations like grid-template.

grid-template: 
            "a a a" 40px
            "b c c" 40px
            "b c c" 40px / 1fr 1fr 1fr;
color: green;

grid-template: 
            "a a a" 40px
            "b c c" 40px
            "b c c" 40px / 1fr 1fr 1fr
color: green

One option would be analizing the indent if semicolons are omitted.
But ident-token cannot contain : or " by specs so it would be very obvious for a parser what token must be an ident-token and what a Component value without relying on indentation.

What do you think?

[astearns]

@timreichen this is a big request, and I don’t think the benefits you outline come anywhere near close to matching the risks involved in making the change. If you want to write without semicolons you can use the original SASS syntax, but as far as I’m aware the SCSS syntax with semicolons is by far the more popular option. Until/unless that kind of developer preference changes, I don’t think we will consider doing this.

[tabatkins]

Yup, afaik SCSS syntax is preferred by a strong majority of the Sass userbase. Less also sticks close to standard CSS syntax; Stylus aligns with Sass by using indents and no semicolons.

A noticeable trend here is that CSS preprocessors tend to either stay close to standard CSS syntax, merely adding some useful features, or they go far from CSS syntax and make indentation matter. If indentation is significant, then semicolons are just visual noise, and should be removed.

I like significant-whitespace languages; Python is my primary programming language at the moment, and I wish it had leaned slightly more into whitespace so I didn't have to use so many :s. But I think you have to commit to that. JS is in a worst-of-both-worlds place, where whitespace is slightly significant, allowing semicolons to be omitted most of the time, but you have to always be on watch for the handful of places where it'll screw you up (like putting something on a newline past a return, or starting a line with an array literal, etc). I really don't want CSS to follow along there.

Notably:

I was always a fan of simplicity for users. If a parser can figure it out by itself without big impact, then let the parser do it.

Simplicity is a difficult sword to wield. Being able to write less characters can look simpler, but if it means users have to memorize more rules about how to format their values, it can backfire and actually make the feature more complex to use. "Properties are always separated by semicolons" (current CSS) is a simple rule; "properties are always indented one level in from their selector, and lines with further indentation are just continuing the previous line" (Sass/Stylus) is a simple rule. "Semicolons can be omitted, but be careful about how you linebreak when you spread a property over multiple lines, because whether or not it interprets you correctly depends on some heuristics" is not a simple rule.

[timreichen]

Agreed, scss is prefered, but afaik not because it uses semicolons to close declarations but because provided some other reasons (article). Also it tries to stay close to the standard which is css, so kinda of a circular argument for this proposal.
I also agree that css should not go by indentation like sass or stylus to omit semicolons.

About JS

I know what you mean. The return of nothing in js is weird, but I think that is not a problem with semicolons/newlines but the fact that JS doesn't have obligatory return values and interprets a single line return like return undefined.
CSS thankfully doesn't do anything like that.

Simple rule

How about: In a block aident-token is followed by a :. All subsequent tokens are Component value until the next ident-token.

The goal of that would be not to make people memorize any complex rules but: You can write a declaration in a block with or without semicolon at the end. Both are handled the same by the parser.

[tabatkins]

Note that all the keywords in properties are ident-tokens as well.