W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

Re: [csswg-drafts] [css-syntax-3]: Voluntary semicolons (#5413)

From: Tim Reichen via GitHub <sysbot+gh@w3.org>
Date: Mon, 10 Aug 2020 18:27:05 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-671515230-1597084024-sysbot+gh@w3.org>
I think we should reconsider because this proposal has multiple aspects it solves:
- 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```.
            "a a a" 40px
            "b c c" 40px
            "b c c" 40px / 1fr 1fr 1fr;
color: green;

            "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```.

What do you think?

GitHub Notification of comment by timreichen
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5413#issuecomment-671515230 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 August 2020 18:27:11 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC