Pseudo-comments in CSS (Or, How Browsers Parse Styles)

The CSS spec does not mention it, but you can mimic C-style and/or Unix-style line comments in CSS files (with some caveats). Others have written about them before (see in particular, SitePoint’s Web Foundations post covering CSS Comments). The present post examines them in further detail.

CSS Comments

CSS parsers, per the spec, officially bless one style for comments, the multi-line comment from C-style languages, which uses a start token, /*, and an end token, */, as follows:

[code language=”css”]
/*
characters between, and including, the start and
end tokens are ignored by the parser,
*/
[/code]

And so a rule declaration in comments will be ignored:

[code language=”css”]
body {
background: red;
/*
background: white;
*/
}
[/code]

A block declaration in comments will be ignored:

[code language=”css”]
/*
body {
background: red;
}
*/
[/code]

In each of those examples, we are using the comment syntax intentionally to instruct the parser to ignore the content.

However, we can do that by accident, as with malformed declarations, such as

[code language=”css”]
body {
background: red /* missing semi-colon */
background: blue;
}
[/code]

In this example, neither background declaration is applied because of the missing semi-colon. The parser scans for the next semi-colon, determines the entire two-line statement is malformed, and so ignores the entire lexed content. The same thing happens if we leave out the property value altogether:

[code language=”css”]
body {
background:
background: blue; /* this declaration is not applied */
}
[/code]

And that shows that we can use malformed declarations as…

Pseudo-comments

We’ll refer to these as “pseudo-comments” because, properly speaking, these are not comments that terminate at an end-of-line character. Instead they work by malforming the input that follows them, even on subsequent lines. And this is due to the error handling process for Rule sets, declaration blocks, and selectors:

“the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.”

In the following example, taken from the spec, the second ruleset is ignored due to the presence of the invalid “&” character in the selector:

[code language=”css”]
h1, h2 {color: green }
h3, h4 & h5 {color: red } /* <= ignored */
h6 {color: black }
[/code]

Again, in the following, the second and third declarations are ignored due to the presence of extra characters in the background property name:

[code language=”css”]
body {
background: red;
xbackground: white; /* property name is not recognized */
y background: blue; /* property name is not well-formed */
}
[/code]

A quick tour around the English language keyboard shows the following special characters will act as single-line declaration comments:

[code language=”css”]
selector {
~ property-name: ignored;
` property-name: ignored;
! property-name: ignored;
@ property-name: ignored;
# property-name: ignored;
$ property-name: ignored;
% property-name: ignored;
^ property-name: ignored;
& property-name: ignored;
* property-name: ignored;
_ property-name: ignored;
– property-name: ignored;
+ property-name: ignored;
= property-name: ignored;
| property-name: ignored;
property-name: ignored;
: property-name: ignored;
< property-name: ignored;
. property-name: ignored;
> property-name: ignored;
, property-name: ignored;
? property-name: ignored;
/ property-name: ignored;
}
[/code]

Rather than use just any character, though, stick with C and Unix convention, and use either # or //:

Continue reading %Pseudo-comments in CSS (Or, How Browsers Parse Styles)%


Source: Sitepoint