Hacker News Reader

Comment by thrusong | Hacker News Reader

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

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

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.

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.

Unless you are commenting out multiple lines/blocks of code.

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.

Commenting a comment is still a comment.

// => ////

//////////////////////////////////////////////////////////////

// just like those devs that like to decorate their code with

//////////////////////////////////////////////////////////////

* type of stuff

Edit: almost forgot my shell friends

########################

## works too

########################

> Commenting a comment is still a comment

But what about the below, does it work in your language? I assume it may work in some languages but not all.

let a = 1;

/* a is one */

let b = 2;

I can definitely see where that could cause some issues.

Personally, I don't like the /**/ style comments either. I was just playing devil's advocate.

This seems like the worst of both worlds. If you're going to use the /* */ I don't see why you'd bother with // unless it's about recognizing a comment in a single line.

I have done the same type of thing to comment out lines of a json file used for configuration . Append “//“ or something to the beginning of a key that I want to have temporarily “commented out”. (Be careful as some programs might expect those keys not to be there of course.)

Heh, I've done this in strict JSON config files:

    {
       "//": "lets us consume uncompiled protobufs (see issue #123)",
       "extern": "protobuf.js" 
    }

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)`, as quotes are optional in URL values

// is only a comment if there is only whitespace directly before it?

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

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.) There, this concept is called a scheme-relative URL (a much more sensible name): 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” and it uses this knowledge to rewrite URLs inside the page, https://1.example/path/to/bar into bar, https://1.example/path/from into ../from, https://1.example/baz into /baz, https://2.example/ into //2.example, and http://1.example/ into http://1.example.

I love it too, which is why I use Sass/SCSS, a gentle extension of CSS.

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.

Reply on news.ycombinator.com