Why doesn’t CSS support double slash (//) comments?

As we all know, CSSonly multi-line comments are supported, that is, /**/comments

/* This is a CSS comment*/ 
div {
   color : red;
}

Students who are used SCSSto LESSthese preprocessors will definitely hope for double slash comments.

// SCSS comment 
div {
   color : red; // SCSS comment 
}

Obviously this way of writing is /**/much more concise, so why doesn’t the official support double slash comments?

Let’s discuss this issue and CSSsome thoughts on grammar.

Contents

1 1. Grammatical conflict
2 2. Incompatible with current version
3 3. Other ways of writing comments
4 4. CSS syntax has never changed.
5 5. Final summary

1. Grammatical conflict

CSSMost of the attributes and values in are relatively simple. At first glance, it seems that there is no syntax with double slashes //. In fact, this is not the case. It is just very few, but it is not none.

For example, here are border-imagesome ways to write

border-image – CSS: Cascading Style Sheets | MDN (mozilla.org)

/* source | slice */ 
border-image : linear-gradient (red, blue) 27 ;

/* source | slice | repeat */ 
border-image : url ( "/images/border.png" ) 27 space;

/* source | slice | width */ 
border-image : linear-gradient (red, blue) 27 / 35px ;

/* source | slice | width | outset | repeat */ 
border-image : url ( "/images/border.png" ) 27  23 / 50px  30px / 1rem round space;

See the grammar in Chapter 4. There are two slashes. The key is that the one between the two slashes widthcan be omitted. This border-imagecan be seen from the grammar specification.

border-image =
  <' border-image-source '> ||
  <' border-image-slice '> [ / < 'border-image-width' > | / < 'border-image-width' >? / < 'border-image-outset' > ] ? ||
  <' border-image-repeat '>

Did you see the question mark<'border-image-width'> behind it ? This means optional, so theoretically it can be written as followsborder-image

border-image : 0 // 0 ;

This way of writing is actually equivalent to

border-image-source : none;
 border-image-slice : 0 ;
 border-image-width : 1 ;
 border-image-outset : 0 ;
 border-image-repeat : stretch;

We can open the console to verify the legality of this syntax

As you can see, this way of writing is completely effective (regardless of the actual function for now)

Therefore, the double-slash syntax may cause syntax conflicts .

There is also a border-imagesimilar attribute called -webkit-mask-box-image, which can also implement double slash syntax

-webkit-mask-box-image – CSS: Cascading Style Sheets | MDN (mozilla.org)

-webkit- mask -box-image: 0 // 0 ;

These are the two I can think of at the moment. If you know of others, please leave a message and add them👏🏻.

However, this is a small part after all, and if there are new regulations, it will be easy to avoid this problem. What’s even more terrible is actually the following reason. If it is supported, all previous CSS specifications may collapse!

2. Incompatible with current version

Why do you think this problem is bigger? We can think about it from another angle, what if CSS now supports double slash syntax?

for example:

< div > CSS COMMENT </ div >

Added a line of comments below

div {
   font-size : 30px ; // font size
   background-color : yellow;
   color : blue;
}

If the browser supports this feature, it is very intuitive. If the browser does not support it (at this stage), what do you think the final style will be?

A. 30px font size, yellow background, blue text
B. 30px font size, blue text
C. Yellow background, blue text
D. Blue text
E. All ineffective, default style

Think for two minutes…

🤔

The answer is B , did you guess it right?

Why is this happening? This is “attributed” to CSS’s powerful and precise “fault-tolerant” parsing rules:

There are no

newline rules in CSS parsing. Each attribute and corresponding value

;are distinguished by a semicolon. Within the selector, if an illegal statement is encountered, it will be searched for the next one

;in sequence, or it can be

{}distinguished by blocking.

The above paragraph is a set of rules I summarized myself. It may still be a little difficult to understand. Take the above example, you can connect the two lines and read it, which is actually equivalent to

div {
   font-size : 30px ;
  // Font size background-color : yellow;
   color : blue;
}

That is to say, it // 字号 background-coloris regarded as a new attribute, but this attribute is invalid, so the final performance is30px字号，蓝色文字

This brings about a very serious problem, which produces unexpected parsing errors on browsers that do not support comments. That is to say, the general incompatible syntax just does not work, but this kind of comments affects other Style, this is the most important thing .

3. Other ways of writing comments

Let’s take a look at some common ways to write comments and see what side effects they have.

< div > CSS COMMENT </ div >

First the most common comments

div {
  // font-size : 30px ; 
   background-color : yellow;
   color : blue;
}

This way of writing is actually in line with expectations and can be parsed normally at this stage because //the first one will be found backwards ;, which means the entire line // font-size: 30px; is invalid .

Then there is this comment

div {
  // title
  font-size : 30px ; 
   background-color : yellow;
   color : blue;
}

According to the previous analysis, it can actually be equivalent to

div {
  // Title font-size : 30px ; 
   background-color : yellow;
   color : blue;
}

So the first line is invalid and the result is the same as before.

If you need not to affect the existing style, you can add it later ;to terminate the parsing directly, as follows

div {
  // title;
  font-size : 30px ; 
   background-color : yellow;
   color : blue;
}

Then there is the writing outside the selector

< div > CSS COMMENT </ div > 
< p > CSS COMMENT </ p >

// Title 
 div {
   font-size : 30px ; 
   background-color : yellow;
   color : blue;
}
p {
   color : red
}

How to analyze this?

In fact, you can think of this comment as a selector, that is, divconnected to the following

// Title div {
   font-size : 30px ; 
   background-color : yellow;
   color : blue;
}
p {
   color : red
}

Since such a selector does not exist // 标题 divand is not a legal selector (slashes need to be escaped), the entire DIVstyle is completely invalid, but it does not affect the style of the subsequent selector ( p).

If you need not to affect the existing style, you need to add it at the end {}to tell the browser that this is a block, as follows

// title {}
 div {
   font-size : 30px ; 
   background-color : yellow;
   color : blue;
}
p {
   color : red
}

4. CSS syntax has never changed.

CSS has been developing for so many years, and various attributes and new features have emerged one after another. In fact, the core grammatical rules have never changed, and this was decided at the beginning of the design.

Like the CSS variables that appeared before

:root {
   --c : red;
}

In essence, it is a special attribute. Even if the old browser does not support it, there will be no other impact, as if it does not exist.

This is why CSS can’t put syntax directly on the outermost layer like SASS, like this

--c : red;
 div {
   color : var (--c)
}

divIf you follow the CSS parsing rules, it will inevitably lead to the overall failure of the following styles.

@There are also new syntaxes for some symbols, e.g.@property

@property --speed{
  syntax: '<number>' ;
  inherits: false;
  initial-value: 0 ;
}

In fact, from a structural point of view, @font-facethere is no difference between

@font-face {
   font-family : "Trickster" ;
   src : xxx;
}

In other words, it also satisfies the following more general format:

Selector {
  Attribute 1 : value;
  Attribute 2 : value;
}

So even if it is not supported, it will not affect other CSS statements. Think about it again, what new features will make other styles “hang”?

5. Final summary

Now you can probably understand why double slash syntax is not supported. The above are some thoughts about CSS syntax. I believe everyone has a new understanding of CSS syntax. Let’s summarize it below

Some attribute values will have double slash syntax, for example border-image,-webkit-mask-box-image
The main reason why double slash comments are not supported is that it is not compatible with current versions and will have side effects on existing CSS.
In order to be compatible with existing versions, new CSS features cannot affect other CSS statements, and the syntax rules have never changed.

It’s safe to say that there will be no rule for double slash comments in CSS in the future. In addition, many of the opinions and conclusions in this article are summarized and have not been traced to official information. There may be some inaccuracies or errors. Welcome to enlighten me in the comment area. Finally, if you think it is good and helpful to you, please like, collect, and forward ❤❤❤

By mucktubeJune 22, 2023JavaScript