Tab Completion

I'm Tab Atkins Jr, and I wear many hats. I work for Google on the Chrome browser as a Web Standards Hacker. I'm also a member of the CSS Working Group, and am either a member or contributor to several other working groups in the W3C. You can contact me here.
Listing of All Posts

Single Line Comments (//) in CSS

Last updated:

Hi haters! This article is half informative, half tongue-in-cheek. Remember that I'll delete your ass like it wasn't a thing if you're rude!

CSS uses the same "block comment" syntax as the C-like languages - you start a comment with /*, and end it with */.

However, CSS is missing the "line comment" syntax that those languages have, where everything from // to the end of the line is commented out.

People have asked for this syntax to be added repeatedly, but unfortunately our hands our mostly tied - CSS minifiers don't know about line comments, so if we added it and the minifier removed all the linebreaks (as they tend to do), the line comment would accidentally comment out the entire rest of your stylesheet!

That said, CSS does actually already allow you to use //, after a fashion. It's not quite a line comment, but a next construct comment.

That is, whenever you use //, the next CSS construct - either declaration or block - will be "commented out". For example:

.foo {
  width: auto;
  //height: 500px;
  background: green;
}

Here, the // commented out the height declaration.

Similarly:

//@keyframes foo {
  from, to { width: 500px; }
  50% { width: 400px; }
}
@keyframes bar {
  from, to { height: 500px; }
  50% { height: 400px; }
}

Here, the // commented out the first @keyframes declaration.

Note, though, that if you try to use // just for writing comments into your stylesheet, you have to be careful - raw text isn't a CSS construct, so it'll look past that and comment out the next construct in your page:

// Do some stuff.
.foo { animation: bar 1s infinite; }
/* Whoops, the .foo block is commented out! */

Update: Whoops, got my own CSS syntax wrong. Sorry, winkybarf ({};), you're no good.

You can avoid this by ending your text comment with a {} (if you're outside of a rule) or a ; (if you're around some declarations), to let the CSS engine know that you're just kidding around:

// Do some stuff {}
.foo { animation: bar 1s infinite; }
/* Success! */

The astute among you will have noticed (or already known) that using // like this isn't really "commenting out" anything at all. Instead, it's just putting an invalid value into the stylesheet and relying on CSS's error-recovery rules to kill the next construct on the page and then recover gracefully. Because CSS's error recovery is well-defined, you can rely on every browser that implements it correctly to work in the expected way.

That said, this is still potentially a useful trick for those who really don't like having to go to the end of a line to add those */ markers, like me. ^_^

(a limited set of Markdown is supported)

why are we favoring minifiers over common expectations of developers. Tooling evolves and so can we. It's like saying we can't change a standard because my text editor can't highlight that new syntax.

Reply?

(a limited set of Markdown is supported)

So you argument there's no need for single-line comments because you can simulate not having to go to the end of the line by... having to put {} at the end of the line?

Also, I don't buy the minifier argument. Minifiers can change and they do change; e.g. an out-of-date UglifyJS copy would strip out the "use strict" pragma, changing code semantics & potentially breaking it.

If you use new syntax, just use a minifier that supports it. Adding stripping out single line comments isn't so hard. Otherwise, new syntax doesn't require one to use it immediately, devs can wait for tools to catch up.

I think the argument from here against adding single-line comments is just moot. Also, the proposed workaround id terrible & doesn't really silve anything.

Reply?

(a limited set of Markdown is supported)

I can't believe I just read an article by a standards leader advocating the use of a language quirk to approximate a desired feature. Decline to add a feature, sure, but don't say "hey, you can already kinda sorta do this with this one weird trick!"

Anyway, I'm with the people arguing "humans over machines". Tools change in response to implementations; if things break, people change their tool sets or they change their behaviors. This is not like IE7 fearing breaking the web.

Finally, inline comments are already supported by preprocessors, sooo... quit advocating hacks and start advocating tools!

Reply?

(a limited set of Markdown is supported)

Use sass + sublime text. ctrl+/ to comment out line that you are on(single line"//") or select multiple lines(it will and "//" to all selected lines) and then ctrl+/.

Reply?

(a limited set of Markdown is supported)

#11 - Eric James:

Minifiers should should be written to understand // comment syntax and strip these lines out while processing line feeds that are being removed. The resulting minified CSS files would still be correct.

Reply?

(a limited set of Markdown is supported)

It's useful in LESS & Sass because you can setup the processor to ignore any comments that use // and include comments that have /* */

Reply?

(a limited set of Markdown is supported)

I’ll stick with

/*

|| */

where the pipes represent the insertion point and the whole thing is returned by a TextExpander shortcut.

Reply?

(a limited set of Markdown is supported)

If you're using a decent editor, you will have a quick and easy shortcut to comment out a line or a block (eg in Netbeans, press ctrl+slash). So there's really no need to do this just because you're too lazy to type a real comment.

If you must do this, I'd suggest using a leading hyphen instead. It's fewer characters than //, has much the same effect, and isn't going to cause confusion by pretending to be something it isn't.

Reply?

(a limited set of Markdown is supported)

#18 - Owen Jones:

It seems like the arguments against // in CSS apply equally to C, C++, JavaScript, Java etc. E.g.

//function main(args) { commands etc... }

In the above example, the pseudocode function is broken in exactly the same way as a CSS media query would be.

It seems that if // is a bad idea in CSS, it is in C, C++ and all other Bell style languages. The validity of // is dependent on the ability of the coder.

Reply?

(a limited set of Markdown is supported)

I just do something like:

"height: 99" change to "--height:99"

Reply?

(a limited set of Markdown is supported)

Re #5: What's wrong with stripping out the "use strict" pragma? Any browser that doesn't know about this pragma just ignores it anyway. If it would really break code it shouldn't be ignorable.

Reply?

(a limited set of Markdown is supported)

Re #1: Using // + {} for text comments is just backwards. But using // to comment out a whole construct is amazing.

Reply?

(a limited set of Markdown is supported)

Re #1: /* comment*/ is good practice for php developers too.

Reply?

(a limited set of Markdown is supported)

OMG.. fell on the floor when I got to this snippet: "...to let the CSS engine know that you're just kidding around".

Anyway, I think most front-end devs are using a preprocessor like SASS which understands // so I'm not sure this is really much of an issue anymore.

Reply?

(a limited set of Markdown is supported)

Re #27: I've always just used an "X" in front of a declaration or a selector I wanted to disable temporarily. Been using it for at least 6 years now without any adverse effects. Works same as //.

Reply?

(a limited set of Markdown is supported)

Thanks. I found this article useful. There are times where /* */ is difficult to manage. Say you comment out "height" in your first example like /* height: 500px; */. Now you want to comment out all of .foo. You can't put /* */ around another /* */. Yes, you can rename it, etc. Advocating for using this is a different issue. It's good to have the knowledge, but what you do with it is up to you.

Reply?

(a limited set of Markdown is supported)

Re #29: Honestly, I'm sad we didn't take the opportunity to have nesting comments. It's ridiculous that programming languages continue to repeat the old mistakes of having comments that don't nest.

It's not trivial, unfortunately, because comments are syntactically aware - you can use a /* in a string literal and it won't start a comment - but the contents of comments are freeform text, so we can't naively just look for a */ - it might be in a string literal (signifying nothing) or it might be an actual end-comment token.

You've got to, instead, have two kinds of comments: a free-form one that can't be nested, but can contain anything; and a structured one that pays attention to at least basic syntax (it shouldn't actually care about usage errors, because sometimes you comment out stuff you're in the middle of writing, but should just know a basic form of the language's grammar that it can parse to look for proper comment tokens).

I don't know of any language that actually does this, but CSS smuggles this feature in via it's error-correction again - if you use, say, an @comment block to comment out things, it'll nest totally fine, and get taken out by the error-correction so that it's effectively "commented out".

Common Lisp also smuggles this in via its "feature support" macro - if you precede an s-expr by #+foo (where "foo" is any value that doesn't correspond to a real feature in the *features* table) it'll get ignored at read-time. This "nests" because the reader macro implementing it still parses Lisp normally, so it knows when the sexpr ends, and it allows more reader macros (such as itself) to parse in.

Reply?

(a limited set of Markdown is supported)

I've quite enjoyed using this just before a block or in front of a single style declaration. The only issue I see is that the editor I use doesn't understand it so still colour codes effectively commented out stuff as if it's not causeing moments of confusion when looking for issues in CSS. I don't see any reason why this couldn't be standard and integrated into the colour coding of editors - I might just see if it's possible to include that myself.

The possibility of just writing the comment text on a line finished by {} is easy interesting though. That seems more manageable but the idea of the comment only being indicated at the end may seem weird. Why(?) Dunno(!)

Reply?

(a limited set of Markdown is supported)

Re #1: or...because and maybe you're not a programmer.

Reply?

(a limited set of Markdown is supported)

ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

Reply?

(a limited set of Markdown is supported)

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest

Reply?

(a limited set of Markdown is supported)

asdasddscvbfgbfshsns;kldgnmslkfj bnlswfkj nblswkj vlswj oswn vwov oswijnvoiswermvopisnvpisdfnmvosdfjnvlosd fgjdl;sj gpojierpo gijerpiogfjeljvkfdzlkvjbdzsljkvb alkjvba;selrjgb;raejvb;aerjinbalkerjbvlakerjvblakjbvlkajsdbvlakjsdbvlkjasdvbjksadv jasjdgasdfads flhfsda

Reply?

(a limited set of Markdown is supported)

Javascript has line comments and minifiers that handle it.

Reply?

(a limited set of Markdown is supported)