Multiline SASS comments

Anahkiasen commented 12 years ago

Currently in SASS you can do

/**
* This to do
* multine comments
* that will output in the CSS
* depending on the mode
*/

// This for multiline comments
// That will not output
// in the CSS

/**!
* This to do multiline
* comments that will always output
*/

To me the second syntax is really painful to use whereas the /* */ syntax is a standard. Wouldn't it be possible to add a flag, just like !, that would just mean "hide that particular comment", allowing to use the /* */ syntax for multiline comments while still hiding it from the CSS output ?

nex3 commented 12 years ago

I don't think this style preference warrants the addition of new syntax. There are already two ways of writing silent comments (// and compressed mode); I don't think there need to be any more.

If you really want, you can monkeypatch Sass to silence /* */ comments as well.

WebDevCA commented 11 years ago

There should be a way to comment out a multi-line block of text that doesn't involve doing something on every single line of the block.

jaydenseric commented 11 years ago

I agree with @WebDevCA. I have several terminal commands commented at the top of some of my SCSS files that I would like to be able to copy and paste into the prompt as a block without having // screwing with each line. These comments only relate to Sass stuff and should not appear in the compiled CSS. I should not be restricted to compressed mode for this, I don't want to lose the comments all together in the CSS. Surely something like this would be a simple syntax:

//*
Multiline comment here.
Second line of comment.
*//

Usage would be far from edge-case, Sass is all about mixins, which are getting more complex and and deserve proper multi-line introductory comments documenting your code as you would in JS or any other language. These sorts of comments should not appear in the compiled CSS.

As an example of the syntax effort people are going through: https://github.com/thoughtbot/bourbon/blob/master/app/assets/stylesheets/css3/_background.scss

kumarharsh commented 10 years ago

Although I agree with your points @jaydenseric and @WebDevCA , do keep the fact in mind that the compiled css must be compressed before distribution for production, thereby removing all the comments (excepts ones starting with !). And for development, it just doesn't matter how long or useless the comments are in your css file.

jaydenseric commented 10 years ago

@kumarharsh Would you support deprecating and removing nested, expanded and compact output styles then?

Comments are a part of the CSS spec. Sass is about making CSS easier. There are times developers want to compile Sass to readable CSS, comments and all.

kumarharsh commented 10 years ago

No I would NOT support deprecating and removing nested, expanded and compact output styles then. Those are features which are already in the library, and the sight of seeing them sacrificed on the altar of our prized multiline silent comments will be a sad sight indeed.

Anyways, for me, (any many many more devs) this issue of commenting-out a block of scss with each line having a // is taken care of by SublimeText and it's Sass plugin. One keystroke is all it takes.

Also, even though I too have wished for something along these lines in the past, I feel @nex3 is right in pointing out that there are enough options to cover all needs.

goztrk commented 9 years ago

I do not agree with @kumarharsh. I think Sass needs some option for disabling required multiline comments on output. Not everyone have to use Sass according to your logic.

For example I am preparing a theme to sell it on Market. So I am using Sass to organise my CSS. I want to add some multiline comments that will helpful to me only on Sass codes. Also I want my CSS files "--expanded" so the customer easily look into css codes and make the replacements for his use.

On another scenerio; I am building a large amout of mixins that has CSS effects that I can use later on. And I want to add usage of them to the scss file's top. (Eg: some HTML code, some description etc.) I can use "//" comments to make this but when I try to copy the HTML code, I am removing all "//". Yes, with some text editors you can easily remove them. But not everyone have to use Sublime Text to write his own code. Everyone has its own preferences. So I believe It's not that hard to add a feature to disable some multiline comments. And I think this feature is required for most of people.

diessica commented 9 years ago

I do not agree with @kumarharsh too. It's not right to simply assume practices and an environment like that, it's just the easiest way to make points.

Some people want to document their code in a readable way (come on, don't say that a lot of // is as readable and organised as /** [..]), and they don't want it to be in the CSS file. I don't think it is hard to understand at all.

do keep the fact in mind that the compiled css must be compressed before distribution for production

Also, there are some code I don't want neither to compress nor minify. Yes, it is that simple.

Anyway...

Solution for multiline Sass comments

// Multine comment
   Indent the text
   And this will be a comment too

body {
   background: tomato;
}

GitHub's syntax higlight isn't working properly. See screenshots below.

Input

Output

I tried it on CodePen. :-)

RicardoAbad commented 8 years ago

For me this comment works and ouput comment in the css file:

/**!
    * CUSTOMIZED
    * Elements
    */

Has to be indented

ergose commented 7 years ago

I heavily disagree with @kumarharsh's comment. Not having a quick two line way to comment out a block from the output is still irritating as heck. Even if I could install a ST3 module, sometimes I'm not on my box or working in code in who-knows-what editor. No one wants to develop across boxes and worry about yet another setup/module to get working just to get work done.

Here's the dreaded use case where this becomes a painful problem... I'm learning a new technique. I want the example or some kind of comparison scss in the same file so I can come back months later and always have it there for reminder in case I need it again and forgot the "why do this/why did I choose x technique over the others". Maybe the old way has 20 lines that need to be commented out from a copy-paste. The new way is short, snazzy, Cali approved, and only 3 lines with mixins! ;) In the 'pretty' compiled version for debugging, I don't want any of these comments, just mine. I also don't want to do '//' 20 times if not in ST3.

Relying on stripping out comment at compile completely misses this common developer use case. Don't get me wrong, I absolutely love Sass. I swear by it all of the time, but this kind of functionality should be built-in, even if it's in an odd way. If someone puts in a pull request for it that won't break anything then it should go in.

reicek commented 6 years ago

I also strongly disagree with @kumarharsh . Mostly, you are ignoring standards and imposing your personal preferences all the way to tool level, that is a terrible thing to do.

This is against standard coding conventions for web development
It's very annoying not being able to comment a whole block (for whatever reason)
Assuming (and forcing) devs to depend on a specif editor is bad practice
You are making SASS opinionated against a standard practice so it's counter intuitive for most devs

kumarharsh commented 6 years ago

Ugh. No need to beat up a 6 year old dead issue. Please open a new issue if it's still a problem.

As for @reicek's comment;

If you can accept sass's nesting and & which are not in standards, you'll see that the comments styles are also the same. 2 & 3. Nearly all major editors have line-level commenting/uncommenting features. Even vim would let you do it without much fuss.
See point 1.

But that said, @gkhno has a very valid point - and I'd say it warrants some more consideration from the author. And @diessica has a good workaround too.

As for my viewpoints on the issue, I don't care much if the feature is included or not. I stopped using Sass due the compass dying out and autoprefixer, css-modules, etc becoming mainstream. But I'm not even a contributor here, so my original comment shouldn't have had held much weight. Keep making noise, and maybe @nex3 would reconsider.

reicek commented 6 years ago

Hi @kumarharsh , sounds like you are taking it a little personal, please don't ;) the only intention here is to collaborate on making things better :)

Block comment a feature based on a standard, using & is an extension of CSS and a valuable feature, just like mixings. I wouldn't put it on the same category.

Agree with the editors option, I personally consider using single line comments for block commenting a bad practice, even if you can toggle them using the editor.

I disagree on opening a new issue, since this one is already there and still valid, it's not a new thing and its not the same to think "this is a new issue" than "this has been an issue since 2012".

I don't use SASS on my personal projects anymore, but at work we are using it since its a large corporation and SASS it's the internal standard. Personally I prefer using SCSS over SASS.

There are alternatives and workarounds, but the fact that people still talks about this should be an indicator of its relevance.

It's not the end of the world, but I hope @nex3 gives this a second thought.

nex3 commented 6 years ago

There are a number of reasons we don't intend to change this behavior:

SCSS is a superset of CSS, and we want to treat plain-CSS syntax the same way CSS does if at all possible. If you pass a valid plain CSS file to Sass, Sass should emit essentially the same CSS as output. This means passing through multiline comments as well.
For users who want to produce CSS output that's human-readable, it's important to provide a way to include comments that explain the meaning and use of the styles that exist in that output.
For users who don't care about human-readable CSS output, there's the compressed style which does strip out multiline comments.

Changing the default behavior here is a non-starter, and adding additional configuration seems like unnecessary complexity given that this is already fairly configurable using the output style.

reicek commented 6 years ago

Thanks for the quick and thorough answer @nex3 !

I agree with all your points. Certainly multi-line comments are not expected on SCSS for the reasons you mention.

The multiline comment feature I was mentioning is for SASS, adding this option as part of the sugar syntax that makes it so appealing for many.

Personally I prefer SCSS, but at work we are using SASS and today this multiline thing came up within the team, as a mean of temporally disabling a block of code, without commenting all lines one by one.

Specifically we were looking for the option of something like this (for SASS):

/* 
body
  display: flex
*/

Instead of:

/* body /*
/*   display: flex /*

Or even better:


/* temporally disabled block
body
  display: flex
//*/

//* temporally active block
body
  display: flex
//*/

Happy weekend (& new year)!

nex3 commented 6 years ago

Sorry, you're right, I misunderstood the issue.

This isn't something I'm opposed to in principle at this point, but coordinating new syntax across all three implementations takes a lot of work and I'm not sure this is worth it. That's especially true here, because we'd need to add behavior for /* that varies substantially based on whether there's a matching */ or not, which would be very complex.

reicek commented 6 years ago

Hi again!

It's understandable, this is certainly not a necessity but a nice-to-have feature with a very low priority since there is the option to use line-by-line comments using features included in most code editors.

We are happy that we successfully raised awareness about this and agreed on the concept.

My team sends their appreciation for SASS team's hard and excellent work. The women of the team were happy to know about you.

jack-fdrv commented 2 years ago

If there any way how i can keep comments with compressed?

nex3 commented 2 years ago

Any comments you write that begin with /*! will be preserved no matter the compilation style. Otherwise, Sass will always discard comments in compressed mode.

sass / sass