Why doesn't CSS allow single-line comments? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this 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?

Answer 1

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

Answer 2

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.

Answer 3

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.