Today does not cause a problem. But what about tomorrow? You should not use anything that is not in the specification precisely because it is not future proof . If you use this and in the future the specification will say that this is for something else or even some browser resolve to do it on its own, you are chipped and it will be your fault.

I've seen a lot of software stop working when the operating system version changes. Almost always the fault is of the programmer who did not follow the specification, he did what seemed to work. It works until the day it no longer works. There he speaks ill of Bill Gates.

Remember that being invalid is very different from determining that information is just a comment. Even giving the same result you are doing wrong and you can pay a price for it. Even if you do not know what it is. So never use something wrong.

BTW, the cited example is called comment out , a technique that should normally be avoided, especially in production code.

Documentation .

Complementing the other answers: this example does not give a problem because it is at the beginning of the line, but in the end it can give a problem. For example:

div {
    background-color: cyan;
    background-color: red; // isto não é um comentário
    border: 2px solid green;
}

In this case the border rule would be completely ignored. As others have said, use comments as per specification, ie always /* */ .

Comments on CSS with // do not exist. The correct syntax is to use /* */ in all cases.

One-line comment:

body {
    /* margin: 0; */
    padding: 0;
}

Comment from n lines:

/* body {
    margin: 0;
    padding: 0;
} */

At first there should be no problem. The precaution that is usually taken when using this type of comment is to be careful to close all open tags.

To complete a little bit of what has already been said, and in the hope of not creating any redundancy of information, the big reason why we can not escape the rule regarding WEB development, particularly HTML, CSS and JavaScript, is that the code that we create will be interpreted by a browser, which is development solely and exclusively on the standards created for each language.

Not enough of the various problems we have with developing code that will behave the same way in different browsers, if we develop code that works by a "mere chance," it becomes even more complicated .

Examples

Based on the code of your question, the // to signal a comment follows 3 practical cases, where the first is just to point out the correct way to identify a comment in CSS so that the browser knows what to do, being the other two examples an illustration of potential problems:

Example 01 - Correct Use

A scenario with comments within what browsers expect to receive since the standard so-called , where we can observe several methods to apply comments and all of them valid:

/* texto de aviso grave */
p {
  color: red; /* vermelho */
  text-transform: uppercase;
}

/*
 * A partir daqui seguem estilos para a conta do utilizador
 * -------------------------------------------------------- */
p {
  font-size: 2em;
}

<p>Super BuBu</p>

Example 02 - Ignored Declaration

Comment incorrectly that will lead the browser to ignore the statement, because according to CSS standards any error will result in the ignored statement.

In the example, the browser will ignore everything from // to the closing of the declaration that is identified by the character } :

// texto de aviso grave
p {
  color: red; /* vermelho */
  text-transform: uppercase;
}

/*
 * A partir daqui seguem estilos para a conta do utilizador
 * -------------------------------------------------------- */
p {
  font-size: 2em;
}

<p>Super BuBu</p>

Example 03 - CSS compression, ignored statement and invalid comment stays in resulting code

Assuming that I've used a server-side code to get the whole CSS into a single line, which also removes comments, a technique most commonly known as compression.

As at first I have a comment with // , it will stay in the code after compressed, and I will still lose the first statement, this is because the CSS compressor will not collect // as the ID of a comment:

If you pass the CSS from example # 2 by this tool, Online CSS Minifier / Compressor , the result is what we can see in the example in low:

// texto de aviso grave p{color:red;text-transform:uppercase}p{font-size:2em}

<p>Super BuBu</p>