Because // {}; is much smaller and easier to type than /* */, right?

Most editors have a shortcut such as CMD + / that would take care of any inconvenience.

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.

// just come naturally :)

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.

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!

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+/.

Because we live in an ecosystem, and things are hard to change.

"One weird trick DOCTORS HATE!"

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.

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

I’ll stick with

/*

|| */

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

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.

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.

I just do something like:

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

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.

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

/* comment*/ is good practice for php developers too.

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.

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

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.

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.

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(!)

or...because and maybe you're not a programmer.

thanks, now thats a trick

Javascript has line comments and minifiers that handle it.

Yeah, minifiers handle it because it's always been there. You couldn't write an effective JS minifier without handling line comments; it would just break on a bunch of code.

CSS doesn't currently have a line comment, tho, so current minifiers don't handle it, and will produce broken code.

Yes, { gets auto-completed by np++ but * is uncomfortable to type (altgr+"-") on a HUN keyboard at least, so for me it's really useful.

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. ^_^

yeah, a minifier could just remove comments...

nice! I've been looking for this

Thanks for sharing, but I am having problem in multi line comment, how to do comment multi-line CSS. I am working for this site https://yesonline.pk/collections/unstitched

It's not smaller, but it's easier to type because / and * are not near each other on the keyboard. Also, although each scheme requires two shifts nominally, in the former scheme the Shifts are consecutive and so can be typed with only a single press of the Shift key.

fdsgfsgf@gfg

sassasasasdsadsvfdbgfbg

https://cssminifier.org/ Get the.... css minifier minify css css minify minify css code css optimize....look here...

sfarfeasfsadfaaefafe

Wow, I really could not agree more. This is really kinda a nutty excuse.

This trick is one less move across my keyboard :D

Single line, or slash-slash '//' comments do, indeed, offer an important benefit to developers. Namely: they nest inside of block (range) style comments '/* ... */'. This allows the practice of using single-line comments for all permanent and informative comments and therefore allowing ranges of lines to be temporary hidden with block style comments. Get it?

it's a nice way of littering your CSS with non-valid code. Otherwise just highlight code, and just use ctrl / shortcut in your text editor

yes, indeed, it is.

Thanks for sharing with us, it is really helpful and informative. However, CSS lacks a “ comment line ” syntax rule , as in these languages, where all the code from / / to the end of the line is considered a comment.

Thanks, simple tut

fhhhhhhhhhhhhhhhhhhhg

Thanks. I had never seen CMD + / and you are right, it does generate /* */ in an editor -- even WordPress. That's a handy tip.

Get a keyboard with a number pad. / and * are right next to each other.

Cool trick! I actually have another comment-based trick of my own, which I call "Code Toggling". Simply put, you put /** at the beginning of the code, and /**/ at the end. To enable the code, replace /** with /**/. To disable it, replace the starting /**/ with /**.

I do that too, and you can even take it up a notch to switch between two versions of code with a single-character change:

/**/
This code runs.
/*/
This code is commented out.
/**/

/**
This code is commented out.
/*/
This code runs.
/**/

The fact that comments don't nest is fun sometimes. ^_^

I Love that intro. Delete your ass.

Funnily enough, it actually is much easier to type

Doesn't that make less/sass break css, since '//' already means something in CSS which is different to a single line comment?

Thanks I just figured this out. Really helped

Because this becomes possible

/* selector { background-color: red; // another: rule // this doesn't work here; } */