无效的CSS选择器导致规则被删除：什么是理由？

本文介绍了无效的CSS选择器导致规则被删除：什么是理由？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 我正在寻找更多的邮件列表讨论等链接，而不是猜测。 任何人都可以帮助我找出引用的错误处理规则背后的理由从CSS 选择器级别3 规范。我有以下规则： / p> #menu li.last，#menu li：last-child { .. 。} 为了弥补IE8缺乏last-child支持，和JavaScript垫片。然而，这没有工作，因为IE8符合CSS规范的错误处理，并丢弃整个规则，因为它不能识别一个选择器。这可以通过将两个选择器分成单独的规则来修复。 为什么这是可取的？为什么规范建议只是舍弃无法识别的选择器，而保留规则的其余部分？ 我想知道原理， 解决方案 答案是因为实现太难以确定什么确切地构成了规则的其余部分（或该选择器列表的其余部分），而不会错误和无意中混乱布局，以及 我将用一个链接来介绍我的长答案到我的另一个答案，对无效选择器的处理。对该答案的评论直接指向CSS2的第4.1.7节。 1 spec ，用于处理规则集中选择器中的错误，其中以选择器中的逗号作为示例。我认为它总结得相当不错：虽然逗号本身仍然意味着分组两个或更多的选择器，就选择器而言，选择器4引入了新的功能接受选择器组（或选择器列表）作为参数的伪类，例如 ：matches（） （甚至更改 ：not（） ，因此它接受一个列表，使其类似于：matches（）在级别3它只接受一个简单的选择器）。 这意味着，不仅你会发现逗号分隔的选择器组与规则相关联，但你会开始在函数伪类中找到它们（注意这只是在一个样式表内;在CSS之外，选择器可以显示在JavaScript代码中，由选择器库和本机 Selectors API ）。 虽然不是迄今为止唯一的原因，但是这本身就足以使解析器的错误处理规则过于复杂，规则集，甚至布局。在使用逗号分析错误的情况下，解析器将难以确定该选择器组是对应于整个规则集还是另一选择器组的一部分，以及如何处理选择器的其余部分及其相关联的规则集。而不是试图猜测，冒险猜测错误，并以某种方式打破规则（例如，通过匹配和样式所有错误的元素），最安全的赌注是丢弃规则，继续前进。 例如，考虑以下规则，其选择器在第4级有效，但不在第3级，取自： #sectors> div：not（.alpha，.beta，.gamma）{ color：＃808080; background-color：＃e9e9e9; opacity：0.5; } 一个不明白选择器4的简单解析器可能会尝试将其拆分为共享相同声明块的三个不同选择器，而不是基于单独的逗号的接受列表的单个选择器： #sectors> div：not（.alpha .beta .gamma） 只是丢弃显然无效的第一个和最后一个选择器，留下有效的第二个选择器，然后应该尝试将该规则应用到 beta 类的任何元素？这显然不是作者打算做的，所以如果浏览器这样做，它会做一些意想不到的事情这个布局。通过使用无效选择器舍弃规则，布局看起来只是一点点消息，但这是一个过度简化示例; 当然，选择器解析中的其他歧义也可能发生，这可能导致以下情况： 不知道复杂选择器的结束位置 不知道选择器列表的结束位置 不知道声明块的开始位置 上述组合 $ b $ 在看起来很好的选择器的情况下，所有这些都是通过丢弃规则集而不是玩猜测游戏来解决的。在您的示例中，作为伪类的：last-child 是无法识别的，规范不区分无法识别的选择器和只是简单格式的选择器。两者都导致解析错误。从您链接到的同一部分：通过对：last-child 我假设浏览器能够解析一个冒号后跟一个任意ident作为伪类首先;在现实中你不能假设实现会知道将：last-child 作为伪类正确解析，或者像：lang ）或：not（），因为功能伪类在CSS2之前才出现。 选择器定义了一组特定的已知伪类和伪元素，其名称最可能在每个实现中都被硬编码。最天真的解析器有每个伪类和伪元素的整个符号，包括单/双冒号，硬编码（如果主要浏览器实际上做的话，我不会感到惊讶这与：之前，：之后，：第一个字母和：第一行为 由于实现失败的方法有很多，规范没有区分，使错误处理更可预测。如果选择器无法识别，无论是因为它不受支持还是格式不正确，都会丢弃规则。 这么说，至少有一个讨论，在www风格的公共邮件列表中建议 我还应该提到一些布局引擎的行为不同，比如WebKit忽略一个规则中的非WebKit前缀选择器，应用自己的前缀，而其他浏览器完全忽略规则（你可以找到更多的例子Stack Overflow;这里略有不同的一个）。在某种程度上，你可以说WebKit是原来的规则，尽管它尝试解析逗号分隔的选择器组，尽管这些前缀选择器。 I不要认为工作组有一个令人信服的理由来改变这种行为。事实上，如果有什么事情，他们有一个令人信服的理由不要改变它，这是因为网站多年来一直依赖这种行为。在过去，我们有过滤老版本的IE的选择器hack;今天，我们有用于过滤其他浏览器的前缀选择器。这些黑客都依赖于某些浏览器的相同行为，丢弃他们不认识的规则，其他浏览器如果他们认为它们是正确的，则应用它们。通过识别前缀（或只抛出不能识别的，如WebKit）。如果这个规则要改变，网站可能在这些浏览器的新版本中崩溃，这在我们的多样化（阅读：碎片化）网络中绝对不会发生。 2013年4月，在电话会议中决定这种行为保持不变的原因我假设上面的： - 解决：不采用MQ风格的无效选择器由于Web兼容的问题。 媒体查询样式无效是指以逗号分隔的列表中的无效媒体查询 code> @media 规则。 I'm looking more for links to mailing list discussions, etc. rather than speculation.Can anyone help me find out the rationale behind the quoted error handling rules from the CSS Selectors Level 3 spec.I had the following rule:#menu li.last, #menu li:last-child { ...}To compensate for IE8's lack of last-child support, I used a class and a JavaScript shim. However, this didn't work because IE8 complies with the CSS spec on error handling, and discards the entire rule because it doesn't recognise one selector. This can be fixed by separating the two selectors in to individual rules.Why is this desirable? Why doesn't the spec suggest simply discarding the unrecognised selector, but keeping the rest of the rule?I'd like to know the rationale, as the rules currently seem counter-intuitive. 解决方案 The short answer is because it'd be too difficult for implementations to figure out what exactly constitutes "the rest of the rule" (or "the rest of the selector list" for that matter) without getting it wrong and inadvertently messing up layouts, as well as for consistency in error handling, and forward compatibility with future specifications.I'll preface my long answer with a link to another answer of mine, on handling of invalid selectors. A comment on that answer points directly to section 4.1.7 of the CSS2.1 spec on dealing with errors in selectors within rule sets, which mentions commas in selectors as an example. I think it sums it up pretty nicely:While the comma itself still means grouping two or more selectors as far as selectors are concerned, it turns out that Selectors 4 introduces new functional pseudo-classes that accept selector groups (or selector lists) as arguments, such as :matches() (it even changes :not() so it accepts a list, making it similar to :matches(), whereas in level 3 it only accepts a single simple selector).This means that not only will you find comma-separated groups of selectors associated with rules, but you'll start finding them within functional pseudo-classes as well (note that this is within a stylesheet only; outside of CSS, selectors can appear in JavaScript code, used by selector libraries and the native Selectors API).Although not the only reason by far, this alone is enough to potentially over-complicate a parser's error handling rules with a huge risk of breaking the selector, the rule set, or even the layout. In the event of a parsing error with a comma, the parser will have trouble determining whether this selector group corresponds to an entire rule set, or part of another selector group, and how to handle the rest of the selector and its associated rule set accordingly. Instead of trying to guess, risk guessing wrongly and breaking the rule in some way (e.g. by matching and styling all the wrong elements), the safest bet is to discard the rule and move on.As an example, consider the following rule, whose selector is valid in level 4 but not in level 3, taken from this question of mine:#sectors > div:not(.alpha, .beta, .gamma) { color: #808080; background-color: #e9e9e9; opacity: 0.5;}A naïve parser that doesn't understand Selectors 4 may try to split this into three distinct selectors that share the same declaration block, instead of a single selector with a pseudo-class that accepts a list, based on the commas alone:#sectors > div:not(.alpha.beta.gamma)If it simply discards the first and last selectors which are obviously invalid, leaving the second selector which is valid, should it then try to apply the rule to any elements with class beta? It's clearly not what the author intends to do, so if a browser does that, it's going to do something unexpected to this layout. By discarding the rule with the invalid selector, the layout looks just a little saner, but that's an over-simplified example; rules with layout-altering styles can cause even bigger problems if applied wrongly.Of course, other ambiguities in selector parsing can occur too, which can lead to the following situations:Not knowing where the complex selector endsNot knowing where the selector list endsNot knowing where the declaration block beginsA combination of the aboveAll of which, again, are most easily resolved by discarding the rule set instead of playing the guessing game.In the case of seemingly well-formed selectors that are unrecognized, such as :last-child as a pseudo-class in your example, the spec makes no distinction between unrecognized selectors and selectors that are just plain malformed. Both result in a parsing error. From the same section that you link to:And by making that statement about :last-child I'm assuming the browser is able to parse a single colon followed by an arbitrary ident as a pseudo-class in the first place; in reality you can't assume that an implementation will know to parse :last-child as a pseudo-class correctly, or something like :lang() or :not() with a functional notation since functional pseudo-classes didn't appear until CSS2.Selectors defines a specific set of known pseudo-classes and pseudo-elements, the names of which are most likely hardcoded in every implementation. The most naïve of parsers have the entire notation for each pseudo-class and pseudo-element, including the single/double colon(s), hardcoded (I wouldn't be surprised if the major browsers actually do this with :before, :after, :first-letter and :first-line as a special case). So what may seem like a pseudo-class to one implementation might very well be gobbledygook to another.Since there are so many ways for implementations to fail, the spec makes no distinction, making error handling much more predictable. If a selector is unrecognized, no matter whether it's because it's unsupported or malformed, the rule is discarded. Simple, straightforward, and easy enough to get your head around.All that said, there is at least one discussion in the www-style public mailing list suggesting that the specification be changed because it may not be so difficult to implement error handling by splitting selectors after all.I should also mention that some layout engines behave differently, such as WebKit ignoring non-WebKit-prefixed selectors in a rule, applying its own prefixes, while other browsers ignore the rule completely (you can find more examples on Stack Overflow; here's a slightly different one). In a way you could say WebKit is skirting the rule as it is, although it does try to parse comma-separated selector groups smartly in spite of those prefixed selectors.I don't think the working group has a compelling reason to change this behavior yet. In fact, if anything, they have a compelling reason not to change it, and that's because sites have been relying on this behavior for many years. In the past, we had selector hacks for filtering older versions of IE; today, we have prefixed selectors for filtering other browsers. These hacks all rely on the same behavior of certain browsers discarding rules they don't recognize, with other browsers applying them if they think they're correct, e.g. by recognizing prefixes (or throwing only the unrecognized ones out, as WebKit does). Sites could break in newer versions of those browsers if this rule were to change, which absolutely cannot happen in such a diversified (read: fragmented) Web as ours.As of April 2013, it was decided in a telecon that this behavior remain unchanged for the reason I've postulated above: - RESOLVED: Do not adopt MQ-style invalidation for Selectors due to Web-compat concerns.Media query-style invalidation refers to invalid media queries in a comma-separated list not breaking the entire @media rule. 这篇关于无效的CSS选择器导致规则被删除：什么是理由？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！