css - 无效的 CSS 选择器导致规则被删除 : What is the rationale?

Question

我正在寻找更多指向邮件列表讨论等的链接，而不是猜测。

谁能帮我找出 CSS Selectors Level 3 中引用的错误处理规则背后的基本原理规范

User agents must observe the rules for handling parsing errors:

• a simple selector containing an undeclared namespace prefix is invalid
• a selector containing an invalid simple selector, an invalid combinator or an invalid token is invalid.
• a group of selectors containing an invalid selector is invalid.

Specifications reusing Selectors must define how to handle parsing errors. (In the case of CSS, the entire rule in which the selector is used is dropped.)

我有以下规则:

#menu li.last, #menu li:last-child {
  ...
}

为了弥补 IE8 缺乏最后一个 child 的支持，我使用了一个类和一个 JavaScript 垫片。但是，这不起作用，因为 IE8 符合关于错误处理的 CSS 规范，并丢弃整个规则，因为它无法识别一个选择器。这可以通过将两个选择器分成单独的规则来解决。

为什么这是可取的？为什么规范不建议简单地丢弃无法识别的选择器，而是保留规则的其余部分？

我想知道基本原理，因为目前的规则似乎违反直觉。

Answer 1

Why is this desirable? Why doesn't the spec suggest simply discarding the unrecognised selector, but keeping the rest of the rule?

简短的回答是因为实现很难弄清楚“规则的其余部分”(或“选择器列表的其余部分”)的确切构成，而不会弄错并无意中弄乱布局，以及错误处理的一致性，以及与 future 规范的向前兼容性。

在处理无效选择器时，我将用指向 another answer of mine 的链接作为我长篇回答的开头。对该答案的评论直接指向关于处理规则集中选择器中的错误的 section 4.1.7 of the CSS2.1 spec，其中以选择器中的逗号为例。我认为它总结得很好:

CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, 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.

虽然就选择器而言，逗号本身仍然意味着将两个或多个选择器分组，但事实证明，选择器 4 引入了新的函数伪类，它们接受选择器组(或选择器列表)作为参数，例如 :matches() (它甚至更改了 :not() 所以它接受一个列表，使其类似于 :matches() ，而在级别 3 中它只接受一个简单的选择器)。

这意味着您不仅会找到与规则关联的以逗号分隔的选择器组，而且还会开始在功能伪类中找到它们(请注意，这仅在样式表中；在 CSS 之外，选择器可以出现在JavaScript 代码，由选择器库和 native Selectors API 使用)。

尽管目前还不是唯一的原因，但仅此一项就足以潜在地使解析器的错误处理规则过于复杂，并且存在破坏选择器、规则集甚至布局的巨大风险。如果出现带有逗号的解析错误，解析器将无法确定此选择器组对应于整个规则集还是另一个选择器组的一部分，以及如何相应地处理选择器的其余部分及其关联的规则集.与其尝试猜测，冒着猜测错误和以某种方式破坏规则的风险(例如，通过匹配和样式化所有错误的元素)，最安全的做法是放弃规则并继续前进。

例如，考虑以下规则，其选择器在级别 4 中有效但在级别 3 中无效，取自 this question of mine :

#sectors > div:not(.alpha, .beta, .gamma) {
    color: #808080;
    background-color: #e9e9e9;
    opacity: 0.5;
}

一个不理解 Selectors 4 的天真的解析器可能会尝试将其拆分为三个不同的选择器，它们共享相同的声明块，而不是一个带有接受列表的伪类的单个选择器，仅基于逗号:

#sectors > div:not(.alpha
.beta
.gamma)

如果它只是丢弃明显无效的第一个和最后一个选择器，留下有效的第二个选择器，那么它是否应该尝试将规则应用于类 beta 的任何元素？这显然不是作者打算做的，所以如果浏览器这样做，它会变成 do something unexpected to this layout 。通过丢弃带有无效选择器的规则 the layout looks just a little saner ，但这是一个过于简化的示例；如果应用错误，具有更改布局样式的规则可能会导致更大的问题。

当然，选择器解析中的其他歧义也可能发生，这可能导致以下情况:

不知道复杂选择器在哪里结束

不知道选择器列表在哪里结束

不知道声明块从哪里开始

以上组合

再一次，通过丢弃规则集而不是玩猜谜游戏，最容易解决所有这些问题。

在无法识别的看似格式良好的选择器的情况下，例如 :last-child 在您的示例中作为伪类，规范没有区分无法识别的选择器和只是格式错误的选择器。两者都会导致解析错误。从您链接到的同一部分:

Invalidity is caused by a parsing error, e.g. an unrecognized token or a token which is not allowed at the current parsing point.

通过做出关于 :last-child 的声明，我假设浏览器首先能够解析单个冒号后跟任意标识作为伪类；实际上，您不能假设实现会知道将 :last-child 正确解析为伪类，或者像 :lang() 或 :not() 之类的带有功能符号的东西，因为功能伪类直到 CSS2 才出现。

选择器定义了一组特定的已知伪类和伪元素，它们的名称很可能在每个实现中被硬编码。最幼稚的解析器对每个伪类和伪元素都有完整的表示法，包括单/双冒号，硬编码(如果主要浏览器实际上使用 :before 、 :after 、 :first-letter 这样做，我不会感到惊讶和 :first-line 作为 special case )。因此，对于一个实现来说看起来像是伪类的东西对于另一个实现来说很可能是gobbledygook。

由于实现失败的方式有很多，规范没有区别，使得错误处理更加可预测。如果选择器无法识别，无论是因为它不受支持还是格式错误，都会丢弃该规则。简单、直截了当，而且很容易让你头脑清醒。

尽管如此，在 www 风格的公共(public)邮件列表中至少有 one discussion 建议更改规范，因为毕竟通过拆分选择器来实现错误处理可能并不那么困难。

我还应该提到一些布局引擎的行为不同，例如 WebKit 忽略规则中的非 WebKit 前缀选择器，应用自己的前缀，而其他浏览器完全忽略该规则(您可以在 Stack Overflow 上找到更多示例；这里是 a slightly different one ) .在某种程度上，您可以说 WebKit 正在绕过规则，尽管它确实尝试巧妙地解析逗号分隔的选择器组，尽管有这些前缀选择器。

我认为工作组还没有令人信服的理由来改变这种行为。事实上，如果有的话，他们有一个令人信服的理由不改变它，那是因为网站多年来一直依赖这种行为。过去，我们有过滤旧版本 IE 的选择器技巧；今天，我们为过滤其他浏览器添加了前缀选择器。这些 hack 都依赖于某些浏览器丢弃它们不识别的规则的相同行为，如果其他浏览器认为它们是正确的，则应用它们，例如通过识别前缀(或者像 WebKit 那样只抛出无法识别的前缀)。如果这条规则发生变化，网站可能会在这些浏览器的较新版本中崩溃，这在我们这样一个多样化(阅读:碎片化)的网络中绝对不会发生。

截至 April 2013 ，由于我在上面假设的原因，在 Telecon 中决定这种行为保持不变:

- 已解决:不要对选择器采用 MQ 样式的失效
由于 Web 兼容问题。

媒体查询样式失效是指以逗号分隔的列表中的无效媒体查询不会破坏整个 @media 规则。