Allow comment indicators (`/*` and `*/`) to be nested.

RokeJulianLockhart commented 3 weeks ago

Specification Name and URI

Please tag the issue title with the spec's short name, like [css-foo] (this is the name from the spec URL, without a level number unless the issue is specific to that level). If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up.
Please link to the spec section you're talking about, or at least the spec.

I think this could reasonably be attributed to CSS Syntax Module Level 3:

If the next two input code point are U+002F SOLIDUS (/) followed by a U+002A ASTERISK (), consume them and all following code points up to and including the first U+002A ASTERISK () followed by a U+002F SOLIDUS (/), or up to an EOF code point. Return to the start of this step.

Improvement

Please be specific (in the title and issue) about what you want to change: “make it better” means different things to different people!

I cannot utilize a custom tag like I can in HTML (<comment>, for instance) which means that for this functionality, I am dependent upon preprocessors, like LESS. However, that's not applicable to mere HTML files.

Luckily, some IDE extensions automatically break the tags in non-standardized manners, like https://github.com/philsinatra/NestedCommentsVSCode/blob/9c25135847af99c89e66b14e7396a3bf2b0d7cf0/README.md#html-syntax:~:text=Examples-,HTML%20Syntax,%3C/main%3E%20%2D%2D%3E,-CSS%20Syntax. However, this is again a problematic barrier to entry, because it assumes that the user's IDE is advanced enough to:

Provide this functionality.
Automatically make the necessary modifications as sections are uncommented and commented, lest the user need to constantly invoke the relevant command.

Other languages, like PowerShell and C++, partially remediate this by providing a non-inline comment indicator. However, this isn't applicable to CSS by design, for it would break its ability to be entirely minified. Consequently, the sole alternative is to permit nested comments.

dbaron commented 3 weeks ago

I think it's likely that there are enough existing stylesheets depending on:

  /* this is a comment
  /* this is also a comment */
  this is not a comment

that this is probably not realistic.

Someone could plausibly make the effort to try to measure whether this is the case. (It doesn't seem worth the effort to me, though.)

RokeJulianLockhart commented 3 weeks ago

https://github.com/w3c/csswg-drafts/issues/10768#issuecomment-2304901248

@dbaron, perhaps. However, your example still requires modification of the comment. Consider what it's like to comment-out a large section of code, which itself is annotated with comments. I have found it infeasible, instead needing to move the code to another file temporarily.

Perhaps the significant interest at https://stackoverflow.com/q/8459988/9731176 demonstrates that other can corroborate this?

tabatkins commented 3 weeks ago

This is the sort of thing you can add when you're designing a language, but can't actually add later, because people end up relying on comment parsing. Unfortunately, CSS went with C rules for this, and we're stuck with them.

For example, it's not uncommon for me to exploit comment parsing to get easy binary toggling of sections when I'm experimenting, like:

/**
this area is initially commented
/*/
this area is initially active
/**/

Because then, with the addition of a single character to the end of the first line:

/**/
this area is now active
/*/
this area is now commented
/**/

This unfortunately means that to comment out large sections that might contain comments themselves, you need the help of a smart editor. Or you can use CSS parsing against itself - any of the brace pairs can effectively toggle stuff by making them invalid (with {} being the easiest, as it triggers rule parsing and doesn't need a closing ; to restart normal parsing).

{
this stuff is *basically* commented out, since the whole block is invalid and dropped
{
and you can nest them
}
so this is still commented out too
}
body::before { content: "normal content here"; }

It's even parsing-aware, so you can have, say, a string that contains an unmatched } and it won't accidentally close your comment, like a string with */ will in normal CSS.

tabatkins commented 3 weeks ago

(You can even spell it @--comment if you like, to make it clearer, and maybe use a double-brace to make it more visually distinguishable, like:

@--comment {{
  this stuff is *basically* commented out, since the whole block is invalid and dropped
  @--comment {{
    and you can nest them
  }}
  so this is still commented out too
}}
body::before { content: "normal content here"; }

)

romainmenke commented 2 weeks ago

Is this something that could be added as a non-normative note?

I like @--comment {{}} (or something like it) and it would be nice if author tools would have some form of support for this.

easily comment out a section through keyboard shortcuts
have syntax highlighting as if it is a comment
do not treat it as invalid CSS, but rather just ignore it
drop it when minifying
...

Having a non-normative note, directed at author tools, would make it easier to get tools to align on this.

RokeJulianLockhart commented 2 weeks ago

https://github.com/w3c/csswg-drafts/issues/10768#issuecomment-2306446976

@romainmenke, that's a clever idea. However, replacing /* with @--comment { and */ with } breaks my CSS file(s). I don't know why, but it nevertheless appears to me that that might not be a solution entirely.

I like @--comment {{}} (or something like it) and it would be nice if author tools would have some form of support for this.
Having a non-normative note, directed at author tools, would make it easier to get tools to align on this.

Certainly! Currently, the syntax highlighter applies to their context, which isn't very readable.

romainmenke commented 2 weeks ago

However, replacing /* with @--comment { and */ with } breaks my CSS file(s). I don't know why, but it nevertheless appears to me that that might not be a solution entirely.

@RokeJulianLockhart Can you specify how or what breaks? Maybe a codepen? Is it causing issues in a browser or for author tools?

tabatkins commented 2 weeks ago

Note that using an at-rule like that is only usable between other rules, or between properties if your browser supports Nesting. It's obviously not usable within a property or similar context; those still need to be commented with /*.

If you are following those rules, tho, then it absolutely works, unless you're perhaps using a preprocessor that's breaking on the unexpected content.

RokeJulianLockhart commented 2 weeks ago

https://github.com/w3c/csswg-drafts/issues/10768#issuecomment-2307771679

@romainmenke, it causes the padding to be reduced:

https://github.com/user-attachments/assets/f3b0e698-6b5b-4626-b63d-a4f7213e5e2a

If you want to reproduce this:

romainmenke commented 2 weeks ago

I can't really see what is happening in the screen capture.

But it seems that you are trying to use it to comment out arbitrary CSS and non-CSS things, but not actually to comment out CSS containing other comments.

Likely there are other characters in there that are interpreted as either the start of mor eblocks or an unexpected early close of the @--comment {} block.

Something like this:

@--comment {
  [ /* open ended, unbalanced bracket */
}

* {
  background-color: pink;
}

Or this:

@--comment {
  } /* unexpected early close */
}

* {
  background-color: pink;
}

Keep in mind that you were asking about nesting comments specifically.

If you use regular CSS comments first and something like @--comment {} for further levels, then everything will work.

@--comment {} isn't a real comment. Everything inside it is tokenized and parsed as CSS. It is only assured to be ignored, as any other comment would also be ignored.

w3c / csswg-drafts