css样式兼容、注释_CSS中的伪注释（或者，浏览器如何解析样式）

css样式兼容、注释

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规范没有提及它，但是您可以模仿CSS文件中的C风格和/或Unix风格的行注释(带有一些警告)。 其他人以前也写过关于它们的文章(特别是，参见SitePoint的Web Foundations文章，内容涉及CSS注释 )。 本职位将对它们进行更详细的研究。

CSS注释 (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:

根据规范 ，CSS解析器正式为一种注释提供了一种样式，即来自C样式语言的多行注释，该注释使用开始标记/*和结束标记*/ ，如下所示：

/*
  characters between, and including, the start and
  end tokens are ignored by the parser,
*/

And so a rule declaration in comments will be ignored:

因此，注释中的规则声明将被忽略：

body {
  background: red;
  /*
  background: white;
  */
}

A block declaration in comments will be ignored:

注释中的块声明将被忽略：

/*
body {
  background: red;
}
*/

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

但是，我们可以偶然地这样做，例如使用格式错误的声明，例如

body {
  background: red    /* missing semi-colon */
  background: blue;      
}

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:

在此示例中，由于缺少分号，因此均未应用任何后台声明。 解析器扫描下一个分号，确定整个两行语句的格式不正确，因此忽略整个词法化的内容。 如果我们完全忽略属性值，则会发生相同的事情：

body {
  background:
  background: blue; /* this declaration is not applied */
}

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

“即使选择器的其余部分在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:

在以下示例(摘自规范)中，由于选择器中存在无效的“＆”字符，因此将忽略第二个规则集：

h1, h2 {color: green }
h3, h4 & h5 {color: red } /* <= ignored */
h6 {color: black }

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

同样，在下面的内容中，由于背景属性名称中存在多余的字符，因此将忽略第二个和第三个声明：

body {
  background: red;
  xbackground: white;    /* property name is not recognized */
  y background: blue;    /* property name is not well-formed */
}

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

快速浏览英文键盘，显示以下特殊字符将用作单行声明注释：

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;
}

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

但是，不要只使用任何字符，而要遵循C和Unix约定，并使用#或// ：

// background: ignored;
  # background: ignored;

分号 (Semi-colons)

Semi-colons are the end tokens of rule declarations. Thus, they cannot “comment” text that follows them. In spec-speak, the parser treats a dangling semi-colon as a malformed declaration (a declaration missing a name, colon, or value).

分号是规则声明的结束标记。 因此，他们无法“注释”其后的文本。 用规范的话来说，解析器将悬挂的分号视为格式错误的声明 (缺少名称，冒号或值的声明)。

As shown earlier, when regular multi-line comments are malformed, that is, when start and end tokens are not balanced around a ruleset or declaration, the subsequent declaration or ruleset is ignored by the parser. The following will in effect “comment” out both background declarations because the parser will search for the next end-of-declaration token (the semi-colon) for the affected declaration:

如前所述，当规则的多行注释格式错误时，即，开始和结束标记在规则集或声明周围不平衡时，后续的声明或规则集将被解析器忽略。 以下内容将有效地“注释” 这两个后台声明，因为解析器将为受影响的声明搜索下一个声明结束标记(分号)：

body {
  background:
  background: blue;      /* both lines ignored */
}

That’s fixed by adding a semi-colon after the comment, before the next declaration (thus the background blue declaration will be applied):

通过在评论后的下一个声明之前添加分号来解决此问题(因此将应用背景蓝色声明)：

body {
  background: ;          /* ignored */
  background: blue;      /* processed */
}

The effect is the same with a pseudo-comment on a line missing its semi-colon:

对于缺少分号的行，伪注释的效果相同：

body {
  background: # red   /* ignored */
  background: blue;   /* also ignored */
}

and corrected by restoring the semi-colon:

并通过恢复分号进行了更正：

body {
  background: # red;  /* ignored */
  background: blue;   /* processed */
}

内联与下一行放置 (Inline vs. next-line placement)

This is where the “pseudo” enters into the term “pseudo-comment.” It may be reason enough not to call these “comments” at all as they break from the end-of-line convention of C or Unix-style line comments.

这是“伪”输入术语“伪注释”的地方。 完全有理由不调用这些“注释”，因为它们与C或Unix样式的行注释的行尾约定不符。

A pseudo-comment placed on its own line will suppress a declaration on the next line. In the following, the background will be blue:

放在其自己行上的伪注释将禁止在下一行声明。 在下面，背景将是蓝色的：

body { 
  //
  background: white !important;  /* ignored */
  background: blue;
}

A pseudo-comment placed after a valid declaration on the same line will suppress a declaration on the next line. In the following, the background will be white rather than blue:

在同一行上的有效声明之后放置的伪注释将禁止在下一行声明。 在下面的背景将是白色而不是蓝色：

body {
  background: white; // next line is ignored... 
  background: blue !important;
}

Even a “minified” version of a CSS selector with an inline pseudo-comment will behave as a single-declaration comment. In the following, the first background declaration is ignored due to the presence of the comment token, #, recognized by the parser as terminating at the next semi-colon, and the second background declaration is recognized as well-formed and therefore applied (in this case, blue will be applied to the body background):

甚至带有嵌入式伪注释CSS选择器的“精简”版本也将充当单声明注释。 在下文中，由于注释令牌#的存在，第一个背景声明被忽略，解析器将其识别为终止于下一个分号，并且第二个背景声明被识别为格式正确并因此被应用(在在这种情况下，蓝色将应用于主体背景)：

body { // background: red !important; background: blue; }

选择器 (Selectors)

The same rule-based behavior applies to selectors.

相同的基于规则的行为适用于选择器。

An entire selector ruleset is ignored when the selector is preceded by a pseudo-comment, whether inline

当选择器前面带有伪注释时，无论是否内联，都会忽略整个选择器规则集

// body {
  background: white !important;
}

or next-line:

或下一行：

//
body {
  background: white !important;
}

伪注释作为目标畸形 (Pseudo-comments as targeted malformed-ness)

Pseudo-comments work by taking advantage of the spec’s Rules for handling parsing errors. In effect, they work by exploiting their malformed-ness.

伪注释通过利用规范的规则来处理解析错误而起作用。 实际上，他们通过利用畸形来工作。

未知值 (Unknown values)

“User agents must ignore a declaration with an unknown property.”

“用户代理必须忽略具有未知属性的声明。”

A declaration containing an unrecognized property name will not be evaluated, as, for example, the comment property in the following body ruleset:

包含无法识别的属性名称的声明将不会被评估，例如，以下body规则集中的comment属性：

body {
  comment: 'could be text or a value';
}

非法值 (Illegal values)

“User agents must ignore a declaration with an illegal value.”

“用户代理必须忽略具有非法值的声明。”

The color property defined below is ignored because the value is a string rather than a value or color keyword:

下面定义的color属性将被忽略，因为该值是字符串而不是value或color关键字：

body {
  color: "red";
}

声明和陈述格式错误 (Malformed declarations and statements)

“User agents must handle unexpected tokens encountered while parsing a declaration [or statement] by reading until the end of the declaration [or statement], while observing the rules for matching pairs of (), [], {}, “”, and ”, and correctly handling escapes.”

“用户代理必须通过解析直到声明[或声明]的末尾，同时遵守匹配()，[]，{}，“”和“ ”，并正确处理转义符。”

body {
  -color: red;
}

Declarations malformed by unmatched pairs of (), [], {}, "", and '' are more comprehensively ignored (and therefore more dangerous) than others. And the quoting characters "", and '' are processed differently than the grouping characters (), [], {}.

由() ， [] ， {} ， ""和''不匹配对组成的声明格式不正确，比其他声明更全面地被忽略(因此更加危险)。 并且引号字符""和''与分组字符() ， []和{}处理方式不同。

引用字符 (Quoting characters)

The unpaired apostrophe in the second declaration below will prevent the subsequent declaration in the ruleset from being processed (thus, the background will be red):

以下第二个声明中不成对的撇号将阻止处理规则集中的后续声明(因此，背景为红色)：

body {
  background: red;
  'background: white;  /* ignored */
  background: blue;    /* also ignored */
}

However, a third declaration after the apostrophe will be processed (thus the background will be gold):

但是， 将处理撇号后的第三个声明(因此背景为金色)：

body {
  background: red;
  'background: white;  /* ignored */
  background: blue;    /* also ignored */
  background: gold;    /* processed */
}

In sum, you can’t terminate a single quoting character on its own line.

总而言之，您不能在其自己的行上终止单个引号字符。

分组字符 (Grouping characters)

In general, grouping characters (), [], {} should be avoided as pseudo-comments because they have more drastic effects in that they interfere more extensively with the parser’s block recognition rules, and so will “comment” out more than single declarations. For the sake of completeness, we’ll examine a few of these.

通常，应避免将字符() ， [] ， {}分组为伪注释，因为它们具有更大的影响，因为它们会更广泛地干扰解析器的块识别规则，因此将“注释”多于单个声明。 为了完整起见，我们将研究其中一些。

For example, the appearance of unmatched starting group characters suppresses all subsequent declarations to the end of the stylesheet (not just the ruleset). This is true of commas, brackets, and braces.

例如，出现不匹配的起始组字符会抑制所有后续声明到样式表的末尾(而不仅仅是规则集)。 逗号，方括号和花括号也是如此。

In the following, only the background: red; declaration is processed; all declarations and selectors after that in the entire stylesheet will be ignored:

在下面，只有background: red; 声明已处理； 整个样式表中的所有声明和选择器都将被忽略：

body {
  background: red;

  {  /* *every* declaration that follows will be ignored, 
        including all subsequent selectors, to the 
        end of the stylesheet. */

  background: white;
  color: aqua;
  margin: 5px;

  ...
}

When grouping characters are matched, the grouped and subsequent ungrouped declarations in the ruleset will be suppressed. In the following, the background will be red, not gold:

当分组字符匹配时 ， 规则集中的分组和后续未分组声明将被禁止。 在下面的背景将是红色，而不是金色：

body {
  background: red;

  (
  background: white;
  background: blue;
  background: fuchsia;
  )

  background: gold;
}

A closing comma or bracket will suppress only the next declaration that appears. In the following, the background will be gold:

一个封闭逗号或支架将只抑制出现的下一个声明。 在下面，背景将是金色的：

body {
  background: red;

  ]
  background: white;  
  background: blue;
}

A closing brace, }, however, will suppress all declarations to the end of the ruleset. In the following, the background will be red:

但是， 右括号 }将禁止所有声明到规则集的末尾。 在下面，背景将是红色的：

body {
  background: red;

  }
  background: white;
  background: blue;
}

规则 (At-rules)

At-rules have two forms:

规则有两种形式：

• a body declaration denoted by braces, { ... } (such as @media),

  用大括号{ ... }表示的主体声明(例如@media )，

• a rule declaration closed with a semi-colon ; (such as @charset).

  用分号封闭的规则声明; (例如@charset )。

Pseudo-comments on body-block at-rules behave the same as for selectors (i.e., the entire at-rule is ignored).

主体块规则上的伪注释与选择器的行为相同(即，整个规则被忽略)。

伪注释适用于带有正文块的规则 (Pseudo-comments applied to at-rules with body blocks)

For at-rules containing body blocks, such as @keyframes, @media, @page. and @font-face, the entire at-rule ruleset is ignored when the at-rule is preceded by a pseudo-comment, whether inline

在规则容纳体块，例如@keyframes ， @media ， @page 。 和@font-face ，如果规则前面带有伪注释(无论是否内联)，则会忽略整个规则规则集

// @media (min-width: 0) {
  body {
    background: white !important;
  }
}

or next-line:

或下一行：

//
@media (min-width: 0) {
  body {
    background: white !important;
  }
}

伪注释适用于无正文规则的规则 (Pseudo-comments applied to at-rules without body blocks)

At-rules without blocks, such as @charset and @import, provide a fascinating exception to inline pseudo-comment behavior.

不带规则的规则，例如@charset和@import ，为内联伪注释行为提供了一个引人入胜的异常。

An at-rule with a pseudo-comment after the keyword will be ignored:

关键字后带有伪注释的规则将被忽略：

/* the pseudo-comment before url()
   suppresses the entire @import */
@import // url('libs/normalize.css');

But a pseudo-comment that precedes an at-rule suppresses both the import and the first rule or selector after the import. This is because the parser treats a pseudo-commented @import as a malformed statement, and looks for the next matching braces in order to complete the next ruleset.

但是在规则之前的伪注释会同时抑制导入和导入后的第一个规则或选择器。 这是因为解析器将伪注释的@import视为格式错误的语句，并查找下一个匹配的括号以完成下一个规则集。

Thus, a pseudo-comment before one @import in a series of @import rules will suppress all subsequent @import rules and the first declaration or selector after the last import:

因此，在一系列@import规则中的一个@import之前的伪注释将禁止所有后续@import规则以及最后一次导入之后的第一个声明或选择器：

// @import url('libs/normalize.css');

/* NONE of these loads because previous statement is
   processed as a malformed statement, and the parser
  looks for the next matching braces. */
@import url('libs/normalize.css');
@import url('libs/example.css');
@import url('libs/other.css');
@import url('libs/more.css');
@import url('libs/another.css');
@import url('libs/yetmore.css');

The fix for this is surprisingly simple: just add an empty body block after the comment @import

解决方法非常简单：只需在@import注释后添加一个空的body块

// @import url('libs/normalize.css');

{}  /* now, the next import will load */

@import url('libs/normalize.css');

This is fun for debugging, but that behavior is peculiar enough that you should avoid the pseudo-comments approach to at-rules without body blocks, and use the multi-line syntax instead.

这对于调试很有趣，但是这种行为非常独特，您应该避免对没有正文块的规则使用伪注释方法，而应使用多行语法。

规则和未知关键字 (At-rules and Unknown at-keywords)

“User agents must ignore an invalid at-keyword together with everything following it, up to the end of the block that contains the invalid at-keyword, or up to and including the next semicolon (;), or up to and including the next block ({…}), whichever comes first”

“用户代理必须忽略无效的关键字及其后面的所有内容，直到包含无效关键字的代码块的末尾，或者直到并包括下一个分号(;)，或者直到并包括下一个分号。区块({…})，以先到者为准”

We can illustrate all that by using an unknown at-keyword, @comment, as a custom at-rule alternative to the multi-line syntax. For example, the following at-rule is parsed to the closing brace, }, determined to be malformed, and then ignored:

我们可以通过使用未知的@comment关键字@comment作为多行语法的自定义规则替代品来说明所有这些。 例如，以下规则被解析为右大括号} ，被确定为格式错误，然后被忽略：

@comment { 
  I'm not processed in any way.
}

That looks harmless and readable at first, but due to the presence of the apostrophe in I'm, we’ve reintroduced the quoting character problem (i.e., you can’t terminate the single quoting character on its own line). That means, a subsequent at-rule or selector will also be ignored if our custom @comment’s body is closed on its own line, because the rule’s declaration is malformed by the presence of the apostrophe in I'm:

乍一看，这看起来无害且可读，但是由于I'm存在撇号，因此我们重新引入了引号字符问题(即，您不能在其行上终止单个引号字符)。 这意味着，如果我们的自定义@comment的主体在其自己的行上关闭，则随后的规则或选择器也将被忽略，因为规则的声明由于I'm '中的撇号的存在而格式错误：

@comment { 
  I'm not processed in any way. }

body { background: blue; }   /* this whole block will not be processed either! */

That can be rescued with outer quotes, either inside the braces

大括号内可以使用外部引号将其保存

@comment { 
  "I'm not processed in any way."  }  /* fixed */

body { background: blue; }   /* this block will work */

Or by leaving off the braces and instead terminating the pseudo-comment with a semi-colon, either inline:

或通过省去大括号，而用分号终止伪注释，可以内联：

@comment "I'm not processed in any way.";

body { background: blue; }   /* this works */

or next-line

或下一行

@comment 
"I'm not processed in any way.";

body { background: blue; }   /* this works */

预处理器 (Pre-processors)

The various CSS pre-processors support similar multiline and single-line comments.

各种CSS预处理器支持类似的多行和单行注释。

萨斯 (Sass)

Sass supports standard multiline CSS comments with /* */, as well as single-line comments with //. The multiline comments are preserved in the CSS output where possible, while the single-line comments are removed.

Sass支持带/ * * /的标准多行CSS注释以及带//的单行注释。 多行注释将尽可能保留在CSS输出中，而单行注释将被删除。

source

资源

Compressed mode will normally strip out all comments, unless the comment is preceded by /*!.

除非注释以/*!开头，否则压缩模式通常会删除所有注释/*! 。

However, you can use a single-character pseudo-comment, such as # and the output will contain the commented line.

但是，您可以使用单字符伪注释，例如# ，并且输出将包含注释行。

body {
   # background: red; 
}

减 (Less)

Both block-style and inline comments may be used.

块样式和内联注释都可以使用。

source

资源

It is not clear (to me, at least) whether Less will suppress these comments or print them to the output. From StackOverflow posts, it appears Less will aggregate line-comments at block level.

尚不清楚(至少对我而言)，Less是否会取消这些注释或将其打印到输出中。 在StackOverflow帖子中，“更少”将在块级别聚合行注释。

触控笔 (Stylus)

Stylus also supports multiline /* */ and single-line comments //, but suppresses these from the output if the compress directive is enabled. If you always want multiline comments to print to the output, use Multi-line buffered comments.

手写笔还支持多行/* */和单行注释// ，但是如果启用了compress指令，则会从输出中取消注释。 如果您始终希望将多行注释打印到输出，请使用多行缓冲注释。

Multi-line comments which are not suppressed start with /*!. This tells Stylus to output the comment regardless of compression.

未抑制的多行注释以/ *！开头。 这告诉触控笔不管压缩如何都输出注释。

/*!
 * This will appear in the output.
 */

source

资源

最佳实践 (Best Practice)

“Readability counts.” https://www.python.org/dev/peps/pep-0020/‘>Zen of Python

“可读性很重要。” https://www.python.org/dev/peps/pep-0020/ '> Python的禅宗

Comments can make obscure code more readable, but readability depends on more than one convention. Pseudo-comments in CSS are less about readability than about playing against convention (aka, the parser).

注释可以使晦涩难懂的代码更具可读性，但是可读性取决于多个约定。 CSS中的伪注释与可读性相比，与约定俗成(也就是解析器)的冲突要少。

If you find you need to use pseudo-comments:

如果发现需要使用伪注释：

• Stick to the C and Unix convention and use either // or # for the pseudo-comment delimiter.

  坚持使用C和Unix约定，并使用//或#作为伪注释定界符。

• Place pseudo-comments on the same line before the item to be ignored.
  将伪注释放在要忽略的项目之前的同一行上。

• Use whitespace to separate the pseudo-comment delimiter from the intended rule ~ e.g. # background: ignored;.

  使用空格将伪注释定界符与预期规则分开，例如# background: ignored; 。

Use pseudo-comments:

使用伪注释：

• Use pseudo-comments for debugging, notably when using an interactive CSS edit panel, such as Chris Pederick’s Web Developer extension (chrome, firefox, opera).

  使用伪注释进行调试 ，尤其是在使用交互式CSS编辑面板时，例如Chris Pederick的Web Developer扩展 (chrome，firefox，opera)。

• Use pseudo-comments to prevent individual declarations, selectors, or at-rules with bodies from being processed.

  使用伪注释可防止处理带有主体的单个声明，选择器或规则。

Avoid pseudo-comments:

避免伪注释：

• Avoid pseudo-comments for use with textual descriptions and at-rules without bodies (e.g., @import) ~ use multi-line /* ... */ comments instead.

  避免将伪注释用于文本描述和不带正文的规则(例如@import)〜改用多行 /* ... */注释代替。

• Avoid the quoting characters '', "" ~ they are hard for human eyes to scan and cannot be terminated on their own line.

  避免使用引号'', "" 〜来使人眼难以扫描，并且不能将其终止。

• Avoid the grouping characters (), [], {} ~ they introduce more complicated scanning (and cannot be terminated on their own line).

  避免对字符(), [], {}进行分组(), [], {}因为它们会引入更复杂的扫描(并且不能在自己的行上终止)。

• Avoid pseudo-comments in production code ~ though not “harmful”, they are merely extra bytes at that point.

  避免在生产代码中使用伪注释-尽管不是“有害”，但在那时它们只是多余的字节。

翻译自: https://www.sitepoint.com/pseudo-comments-in-css-or-how-browsers-parse-styles/

css样式兼容、注释