5 ms·

I would like more commenting options in CSS. Doing /* something */ is the only way I know of.

by ape4 5y ago

thrusong 5y ago
// I would love a two-forward-slashes comment in CSS
- ajb92 5y ago
  Me too. I expect though that there'd be lots of breaking changes around existing CSS having, for instance,`background-image: url(https://somedomain.abc/somefile.png https://somedomain.abc/somefile.png)`, as quotes are optional in URL values
  - david422 5y ago
    // is only a comment if there is only whitespace directly before it?
    - mananaysiempre 5y ago
      Note that //foo/bar.txt is a valid address (a “network-path relative URI reference”[1]). Those are rarely seen but are used sometimes when the same resource or snippet needs to be usable with both HTTP and HTTPS. (I think I first learned about this form while reading a text on gradual migration to HTTPS circa 2014.) My impression is this form might actually be the original way of expressing network paths, what with UNC in Windows (\\server\share\file etc.) and POSIX carving out an exception specifically for two slashes at the beginning of a pathname (that is, foo//bar is the same as foo/bar and ///foo/bar is the same as /foo/bar, but //foo/bar may or may not be the same as /foo/bar). [1] https://datatracker.ietf.org/doc/html/rfc3986#section-4.2 https://datatracker.ietf.org/doc/html/rfc3986#section-4.2
      - chrismorgan 5y ago
        On the web, and most of the rest of the internet as well for most practical purposes, WHATWG’s URL Standard is now the normative reference for URLs, and obsoletes IETF’s RFC 3986 and 3987. (Source: https://url.spec.whatwg.org/#goals https://url.spec.whatwg.org/#goals.) There, this concept is called a scheme-relative URL (a much more sensible name): https://url.spec.whatwg.org/#scheme-relative-url-string https://url.spec.whatwg.org/#scheme-relative-url-string. They’re not the most common, but they’re not especially rare, either. HTML compressors especially will normally support emitting URLs in this form—you tell the compressor “this file you’re compressing will be served from the URL https://1.example/path/to/foo” https://1.example/path/to/foo” and it uses this knowledge to rewrite URLs inside the page, https://1.example/path/to/bar https://1.example/path/to/bar into bar, https://1.example/path/from https://1.example/path/from into ../from, https://1.example/baz https://1.example/baz into /baz, https://2.example/ https://2.example/ into //2.example, and http://1.example/ http://1.example/ into http://1.example http://1.example.
- chrismorgan 5y ago
  You kinda can: selector { //property: value; } This sets the property named "//property" to "value". Close enough. (Expressed otherwise: it’s approximately a comment until the next semicolon, barring quoted strings and parentheses.) //selector { property: value; } This is an invalid selector, and so the entire rule is ignored. (Expressed otherwise: it’s approximately a comment until the next opening curly brace’s matching closing curly brace.)
  - zamadatix 5y ago
    Seems like it has plenty of disadvantages but no advantages to simply using the canonical method to do the same hack: /* // blah */ Edit: I mistakenly parsed this as using a dummy selector to hold the comment property, not just putting it inside real selectors.
    - galaxyLogic 5y ago
      It is faster to type // than /* ... */ . Any time you type the same character twice it is much faster than typing two separate characters. Further because I write a lot of JavaScript too I sometimes make the mistake of putting a // -comment into my CSS which breaks things. And when things break in CSS you usually don't get a clear error-message about it. It is always difficult to switch between two languages. I would prefer something like JavaScript stylesheets, if that was possible.
      - dylan604 5y ago
        Unless you are commenting out multiple lines/blocks of code.
        galaxyLogic 5y ago
        True. But the IDE can of course help. In WebStorm I can select multiple lines of code and press Ctrl-/ to have them all turned into single-line comments if they were not, and uncomment them if they were. Single-line comments have the benefit that it is always clear to the reader which lines are comments. Whereas if you use multi-line comments to comment a large section of code it is no longer clear when reading it whether it is indeed "inside" a comment. And finally having both types of comments available is useful because you can multi-line-comment a section which already contains // -comments, whereas you can not multi-line comment a section which already contains multi-line comments.
- nayuki 5y ago
  I love it too, which is why I use Sass/SCSS, a gentle extension of CSS.
  - frosted-flakes 5y ago
    I use SCSS for three reasons: // comments, nesting, and importing stylesheets. SCSS has so much more than that, but I don't use any of it.
danShumway 5y ago
I would not recommend this, I think it's more trouble than its worth, the syntax highlighting isn't going to be great, and I think you're just going to confuse your coworkers, but if you really want to, you can take advantage of the fact that CSS ignores rules that it doesn't recognize. .Component__child { TODO: add theming support } Of course, you have some restrictions around syntax here (again, I didn't say I advise doing this), and of course if CSS ever adds a TODO rule you might run into problems.
- err4nt 5y ago
  Do not practice writing invalid CSS, if this gets out online on the internet it will prevent any read `todo` property from being used because people are camping on CSS's name space. Instead, any author is allowed to invent _any_ property, so long as the property name begins with a double-dash (--) and you can put anything inside as a value so long as it doesn't break CSS syntax a { --note: So you could do this instead and it would be standard CSS, perfectly fine for all people forever! ; }
  - danShumway 5y ago
    Hah, this is my brain thoroughly broken by forced IE-compatibility for so long on legacy apps, but I completely forgot about custom properties when I was writing that comment! You're right, that's a much better solution. I still don't think I recommend it, because sure it gets rid of the problem of accidentally breaking CSS namespace, but I still think in most cases sticking comments inside of a property is going to end up confusing people on a team more often than it will help, and there are still some syntax issues and conflicts with your own internal variables that can happen. But for sure, if you're going to use properties for notes, make them custom properties. ---- Edit: I particularly don't recommend this, but off the top of my head using custom properties you also might be able to rig this up with something like `:before` pseudo-classes to even display some of your CSS comments visibly in the page via `content` or by building style toggles[0] or something. Again, I feel like this is getting too clever for its own good, but as long as we're playing around... [0]: https://css-tricks.com/logical-operations-with-css-variables/ https://css-tricks.com/logical-operations-with-css-variables...
err4nt 5y ago
The reason CSS will never have //-style single-line comments is that the entire CSS language is parsed as a single line, so if you ever entered a //-style single line comment there would be no return from it for the rest of the input stream. (Kind of like the <plaintext> element in HTML, once you write the <plaintext> open tag all text after that is plain text, so you can't write a </plaintext> to get out of it - the whole rest of the file is in that mode with no return)
- jamesfinlayson 5y ago
  Oh I didn't know about that one - I thought I'd misremembered the <pre> tag's behaviour but now I see <plaintext> was deprecated in HTML 2.
acdha 5y ago
Out of curiosity, what editor do you tend to use? Commenting has been a single shortkey for me for so long that I had to remind myself that CSS doesn't support something like the // syntax because my normal editing flow is to either start typing or select text and hit Command+/.
Arrivest 5y ago
If you use css-in-js libaries, "//" just works. At least that's my experience with styled-components.

I would like more commenting options in CSS. Doing /* something */ is the only way I know of.

by ape4 5y ago

I would like more commenting options in CSS. Doing /* something */ is the only way I know of.

thrusong 5y ago

// I would love a two-forward-slashes comment in CSS

ajb92 5y ago
Me too. I expect though that there'd be lots of breaking changes around existing CSS having, for instance,`background-image: url(https://somedomain.abc/somefile.png https://somedomain.abc/somefile.png)`, as quotes are optional in URL values
- david422 5y ago
  // is only a comment if there is only whitespace directly before it?
  - mananaysiempre 5y ago
    Note that //foo/bar.txt is a valid address (a “network-path relative URI reference”[1]). Those are rarely seen but are used sometimes when the same resource or snippet needs to be usable with both HTTP and HTTPS. (I think I first learned about this form while reading a text on gradual migration to HTTPS circa 2014.) My impression is this form might actually be the original way of expressing network paths, what with UNC in Windows (\\server\share\file etc.) and POSIX carving out an exception specifically for two slashes at the beginning of a pathname (that is, foo//bar is the same as foo/bar and ///foo/bar is the same as /foo/bar, but //foo/bar may or may not be the same as /foo/bar). [1] https://datatracker.ietf.org/doc/html/rfc3986#section-4.2 https://datatracker.ietf.org/doc/html/rfc3986#section-4.2
    - chrismorgan 5y ago
      On the web, and most of the rest of the internet as well for most practical purposes, WHATWG’s URL Standard is now the normative reference for URLs, and obsoletes IETF’s RFC 3986 and 3987. (Source: https://url.spec.whatwg.org/#goals https://url.spec.whatwg.org/#goals.) There, this concept is called a scheme-relative URL (a much more sensible name): https://url.spec.whatwg.org/#scheme-relative-url-string https://url.spec.whatwg.org/#scheme-relative-url-string. They’re not the most common, but they’re not especially rare, either. HTML compressors especially will normally support emitting URLs in this form—you tell the compressor “this file you’re compressing will be served from the URL https://1.example/path/to/foo” https://1.example/path/to/foo” and it uses this knowledge to rewrite URLs inside the page, https://1.example/path/to/bar https://1.example/path/to/bar into bar, https://1.example/path/from https://1.example/path/from into ../from, https://1.example/baz https://1.example/baz into /baz, https://2.example/ https://2.example/ into //2.example, and http://1.example/ http://1.example/ into http://1.example http://1.example.
chrismorgan 5y ago
You kinda can: selector { //property: value; } This sets the property named "//property" to "value". Close enough. (Expressed otherwise: it’s approximately a comment until the next semicolon, barring quoted strings and parentheses.) //selector { property: value; } This is an invalid selector, and so the entire rule is ignored. (Expressed otherwise: it’s approximately a comment until the next opening curly brace’s matching closing curly brace.)
- zamadatix 5y ago
  Seems like it has plenty of disadvantages but no advantages to simply using the canonical method to do the same hack: /* // blah */ Edit: I mistakenly parsed this as using a dummy selector to hold the comment property, not just putting it inside real selectors.
  - galaxyLogic 5y ago
    It is faster to type // than /* ... */ . Any time you type the same character twice it is much faster than typing two separate characters. Further because I write a lot of JavaScript too I sometimes make the mistake of putting a // -comment into my CSS which breaks things. And when things break in CSS you usually don't get a clear error-message about it. It is always difficult to switch between two languages. I would prefer something like JavaScript stylesheets, if that was possible.
    - dylan604 5y ago
      Unless you are commenting out multiple lines/blocks of code.
      - galaxyLogic 5y ago
        True. But the IDE can of course help. In WebStorm I can select multiple lines of code and press Ctrl-/ to have them all turned into single-line comments if they were not, and uncomment them if they were. Single-line comments have the benefit that it is always clear to the reader which lines are comments. Whereas if you use multi-line comments to comment a large section of code it is no longer clear when reading it whether it is indeed "inside" a comment. And finally having both types of comments available is useful because you can multi-line-comment a section which already contains // -comments, whereas you can not multi-line comment a section which already contains multi-line comments.
nayuki 5y ago
I love it too, which is why I use Sass/SCSS, a gentle extension of CSS.
- frosted-flakes 5y ago
  I use SCSS for three reasons: // comments, nesting, and importing stylesheets. SCSS has so much more than that, but I don't use any of it.

danShumway 5y ago

I would not recommend this, I think it's more trouble than its worth, the syntax highlighting isn't going to be great, and I think you're just going to confuse your coworkers, but if you really want to, you can take advantage of the fact that CSS ignores rules that it doesn't recognize. .Component__child { TODO: add theming support } Of course, you have some restrictions around syntax here (again, I didn't say I advise doing this), and of course if CSS ever adds a TODO rule you might run into problems.

err4nt 5y ago
Do not practice writing invalid CSS, if this gets out online on the internet it will prevent any read `todo` property from being used because people are camping on CSS's name space. Instead, any author is allowed to invent _any_ property, so long as the property name begins with a double-dash (--) and you can put anything inside as a value so long as it doesn't break CSS syntax a { --note: So you could do this instead and it would be standard CSS, perfectly fine for all people forever! ; }
- danShumway 5y ago
  Hah, this is my brain thoroughly broken by forced IE-compatibility for so long on legacy apps, but I completely forgot about custom properties when I was writing that comment! You're right, that's a much better solution. I still don't think I recommend it, because sure it gets rid of the problem of accidentally breaking CSS namespace, but I still think in most cases sticking comments inside of a property is going to end up confusing people on a team more often than it will help, and there are still some syntax issues and conflicts with your own internal variables that can happen. But for sure, if you're going to use properties for notes, make them custom properties. ---- Edit: I particularly don't recommend this, but off the top of my head using custom properties you also might be able to rig this up with something like `:before` pseudo-classes to even display some of your CSS comments visibly in the page via `content` or by building style toggles[0] or something. Again, I feel like this is getting too clever for its own good, but as long as we're playing around... [0]: https://css-tricks.com/logical-operations-with-css-variables/ https://css-tricks.com/logical-operations-with-css-variables...

err4nt 5y ago

The reason CSS will never have //-style single-line comments is that the entire CSS language is parsed as a single line, so if you ever entered a //-style single line comment there would be no return from it for the rest of the input stream. (Kind of like the <plaintext> element in HTML, once you write the <plaintext> open tag all text after that is plain text, so you can't write a </plaintext> to get out of it - the whole rest of the file is in that mode with no return)

jamesfinlayson 5y ago
Oh I didn't know about that one - I thought I'd misremembered the <pre> tag's behaviour but now I see <plaintext> was deprecated in HTML 2.

acdha 5y ago

Out of curiosity, what editor do you tend to use? Commenting has been a single shortkey for me for so long that I had to remind myself that CSS doesn't support something like the // syntax because my normal editing flow is to either start typing or select text and hit Command+/.

Arrivest 5y ago

If you use css-in-js libaries, "//" just works. At least that's my experience with styled-components.