13

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?

closed as primarily opinion-based by gnat, zzzzBov, Eric King, Jörg W Mittag, user22815 Aug 24 '16 at 15:00

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    That's a poor decision. They should allow single line comments. – Tulains Córdova Aug 22 '16 at 20:22
  • 1
    @Goose: have you looked at sass-lang.com ? – kevin cline Aug 22 '16 at 20:28
  • 2
    related: stackoverflow.com/questions/2479351/… – Eric King Aug 22 '16 at 22:38
  • 1
    @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
  • 2
    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
8

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.)

  • Oh, // is a token in CSS? Do tell. – Michael Blackburn Aug 23 '16 at 15:53
  • Currently // will be parsed into two "delim tokens" with in turn is not allowed anywhere in the grammar. See 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
8

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.

  • JavaScript also supports single-line // comments. – Tulains Córdova Aug 23 '16 at 12:49
  • 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 8 '18 at 22:04
-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.

  • 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
  • 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

Not the answer you're looking for? Browse other questions tagged or ask your own question.