Why doesn't CSS allow single-line comments?

Question

I understand that CSS only supports multi-line comments like such

/* foobar */

Why is there not support for single line comments.

// foobar

They are just as common in programming and seems particularly useful for a language like CSS where each rule is on it's own line.

If there was no particular historical reason for this decision, what has prevented browsers from moving towards supporting it?

That's a poor decision. They should allow single line comments. — Tulains Córdova, Aug 22 '16 at 20:22
@TulainsCórdova ...and we will vote this question up as a means to [poll](http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6491#6491) in support for that change, right? — gnat, Aug 22 '16 at 20:23
@gnat I would also like to know the rationale behind that design decision. That's why I upvoted. — Tulains Córdova, Aug 22 '16 at 20:25
@kevincline yes, and I actually use less for larger projects. I'm just curious about the history or logic of this design decision, if any. Seems obvious looking back all these years later. — Goose, Aug 22 '16 at 20:52
related: http://stackoverflow.com/questions/2479351/why-do-comments-work-in-stylesheets-but-comments-dont — Eric King, Aug 22 '16 at 22:38
@EricKing That questions's accepted answer chaks it up to facilitating "minification" (elimination of all unnecessary whitespace and newlines so CSS files can transfer more quickly and sometimes to obscure them)... but minification is also used in JavaScript and it supports single line comments (`//`) nonetheless. — Tulains Córdova, Aug 23 '16 at 11:50
@TulainsCórdova I didn't endorse the answers, just pointed out that this discussion has been had already. — Eric King, Aug 23 '16 at 14:49
That question did get an answer that is more technical than the answers here. "CSS treats newlines like all other whitespace, and would not be able to determine the end of the comment without a terminating delimiter." — Goose, Aug 23 '16 at 14:59
It's a legacy technology with strict backwards-compatibility requirements. — Den, Aug 23 '16 at 16:17

JacquesB · Accepted Answer · 2016-08-23T20:09:55.973

Backwards compatibility

Introducing single-line comments to the CSS syntax could change the meaning of files which currently uses the token //. Browser vendors are very reluctant to introduce changes which could potentially break existing pages.

CSS is defined with very precise "error-tolerant" parsing rules which means even if you write something syntactically illegal there are precise rules for how the parse should proceed. If an illegal sequence of characters (like //) is detected inside a declaration, the current declaration is discarded and everything until the next semicolon is skipped.

CSS is designed like this to allow the introduction of new syntax without breaking old browsers. Old browsers will just skip declaration which contain unsupported syntax, and continue after.

But this logic assumes the "unit" to be either processed or skipped is the declaration. If single-line comments were introduced it would mean the parse after // should skip until next linebreak instead of until next semicolon, which changes which rules are parsed and which are skipped. This could potentially change the meaning of existing CSS files in surprising ways.

An example:

P { font: 12px//16px; }
... hundreds of additional lines of CSS...

Here I mistakenly doubled the slash. The consequence is the font-declaration is ignored, but all the rest works fine. If support for //-comments were introduced, suddenly the closing brace would be commented out, potentially breaking all the rest of the style sheet.

Now you could say it's my own fault since I made a mistake, but this doesn't change that an unknown number of pages on the internet might break or render strangely for obscure reasons.

Any such change which breaks backwards compatibility should be considered very carefully, and single-line comments is probably not compelling enough for the risk, since the only benefit is it saves you a few keystrokes.

So if CSS should have singe-line comments it should probably have been introduced from the beginning. But CSS started out as a very simple language and having two different comment syntaxes would have been seen as needless complexity at the time. (Even ANSI C didn't have single-line comments.)

Currently `//` will be parsed into two "delim tokens" with in turn is not allowed anywhere in the grammar. See https://www.w3.org/TR/css-syntax-3/#tokenization for details. — JacquesB, Aug 23 '16 at 16:07
+1 for MainMa for why it started with `/**/`, but accepting this one because it also addresses why it hasn't changed. — Goose, Aug 23 '16 at 19:34

Arseni Mourzenko · Answer 2 · 2016-08-23T12:18:02.497

Supporting yet another syntax element isn't that easy: there are plenty of tools which should be able to handle yet additional comment style. Actually, I wouldn't be surprised to see that most tokenizers/parsers simply ignore newlines, probably replacing them by ;.

If it would be essential to the language, i.e. make developers' lives much easier, this could be done. For instance, not having any sort of comments in CSS would suck, and it would be worth the effort to add specific syntax elements which delimit comments. //-style comments on the other hand?... I don't see the point. See, /* Hello, World! */: a one-line comment.

Actually, you probably expect //-style comments because you are used to them in C++ or similar languages. However, CSS doesn't inherit from C++, so expecting similar syntax features is rather strange.

Similarly, a Python programmer would claim that CSS should also have #-style comments; so now, do we need to support both styles? Then a guy from Haskell world would ask to include -- and {- -} as well, and you'll ask yourself why don't you recognize CSS code any longer.

The tiny benefit of // is that you don't have to type three more characters at the end of your single-line comment (actually, if we start counting characters, CSS should use Python-style comments). However, if you use a decent text editor, you comment/uncomment text simply by pressing a shortcut anyway.

They [...] seem particularly useful for a language like CSS where each rule is on it's own line.

As I explained, they are only slightly useful, for a small subset of programmers, using a small subset of text editors. As for your remark about the each rule on its own line (I disagree with your remark, by the way), this made me think about another point: how the comments are actually used.

Here's the usage of CSS comments I can think of:

As a file header (copyright info, vanity stuff, etc.)
As a delimiter of a group of styles.
As an explanation of a hack.
As a detail about a particular style or property.

In the first three cases, you'll use multiline-style comments anyway. This is obvious for the file header and the explanation of a hack (most hacks require at least a sentence and a hyperlink to StackOverflow or a blog article); as for the delimiters:

/**
 * Footer and sitemap styles.
 */

C-style comment is much more visible than:

// Footer and sitemap styles.

buried in text.

I'd argue that `//` is very common in many languages and the concept behind it is it's more than syntax, it also functions differently. That said, this is the most in depth answer yet. — Goose, Aug 23 '16 at 13:29
I don't think it's a small subset at all. Just about anyone writing CSS in the raw would find it easier to add comments with //. But the backwards compatibility point makes it moot. — O'Rooney, Mar 08 '18 at 22:04
"//-style comments on the other hand?... I don't see the point." It's difficult to comment out a section of CSS (for development) when that section has a comment inside. Maybe I "should" have an easy way to do that with my editor, but at the moment I don't. So, some people would find it useful to have single line comments. — David Winiecki, Aug 30 '22 at 18:30

score -5 · Answer 3 · answered Aug 23 '16 at 15:14

-5

The issue is that most languages with comments (i.e. C#, Java) are compiled languages, and the compiler strips out ALL comments before presenting the content to the consumer (the CPU). CSS is not compiled; generally the file is sent unchanged as the designer developed it, so there is no opportunity to strip out the comments. The // style comment then requires both the // symbol AND a line feed to retain syntactic correctness.

Yes, minifiers exist, and yes, javascript allows this type of comment. Javascript also allows eval() so I don't think we want to take it as a model.

answered Aug 23 '16 at 15:14

Michael Blackburn

476
2
10

3

This answer does not make any sense at all. "There is no opportunity to strip out the comment" - of course there is, the comment is stripped out by the parser exactly like in any other language. Otherwise how could CSS have the `/* */` comments? – JacquesB Aug 23 '16 at 15:27
I meant third-party intermediary between the designer and the consumer. The compiler is this intermediary in compiled languages. The "parser" you refer to is a subsystem of the browser, the ultimate consumer of the content. – Michael Blackburn Aug 23 '16 at 15:30
So why cant the parser strip out `//` comments when it can strip out `/* */` ? – JacquesB Aug 23 '16 at 15:33
1

It could, but then it has to look for both the // and the line feed, and line feeds are predominantly semantic content, not syntactic. CSS as designed treats all whitespace the same. To support // you now have "special" whitespace and furthermore, that "special" whitespace might be one character (\n) and it might be two (\r\n). – Michael Blackburn Aug 23 '16 at 15:35
But..every other programming language can do this, you even point out JavaScript does it. – JacquesB Aug 23 '16 at 15:40
I'll assume when you say "every other language" you mean allow single-line comments, since there arehundreds of languages which don't use // as a comment. Now, it's true that many *imperative* languages do allow single line comments, but an imperative language operates on a statement-by-statement basis. CSS is a declarative language, meaning it defines a structure, but doesn't specify a logical flow. Single-line comments are easy to understand in an imperative language because it just ignores the whole statement and moves to the next command. – Michael Blackburn Aug 23 '16 at 15:51
Vis JavaScript, there's a damn good reason why dozens of other languages "compile to" JavaScript. Its syntax is a hot mess, and certainly shouldn't be used as a style guide. https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js – Michael Blackburn Aug 23 '16 at 15:52
@MichaelBlackburn SQL is also declarative and allows single line comments `--` . – Tulains Córdova Aug 23 '16 at 16:20
3

@MichaelBlackburn: DSSSL (which is a predecessor to CSS using S-expression syntax) also have single-line comments. It has nothing to do with imperative versus declarative languages. – JacquesB Aug 23 '16 at 16:33
Oh, so they had it and decided to take it out? Hmm.. – Michael Blackburn Aug 25 '16 at 04:18
SQL is a declarative language. The languages which you use to create SQL procedures, are procedural -- those languages are properly called T-SQL or PL/SQL. The answers to this question might help you understand better. http://stackoverflow.com/questions/1043265/what-is-the-difference-between-sql-pl-sql-and-t-sql – Michael Blackburn Aug 25 '16 at 04:32
DSSSL is reaching WAAAAY back. That was based on a functional language called Scheme. – Michael Blackburn Aug 25 '16 at 04:33

Why doesn't CSS allow single-line comments?

3 Answers3