计算CSS选择器专用性for：not（）伪类 [英] Calculating CSS selector specificity for :not() pseudo-class

问题描述

我已经知道如何计算CSS的选择器特性（在规格中提到的a / b / c / d）。但是，我无法确定如何计算它：not（）伪类。请参阅以下示例：

 输入：not（[type =text]，[type =password]，。 someClass）{...} 
输入：not（#someId [type =text]）{...} 
  

假设它们都适用于一个元素，那么这两个元素是否计算为（0011），因此它们应该按照出现的顺序排序？或者应当根据哪一个匹配来单独地进一步计算：not（）伪类中的选择器，作为确定优先于其他？

解决方案

假设它们都适用于一个元素， 0011），因此应按照外观的顺序排列？或者，应当根据哪一个匹配作为第二步来确定优先于另一个的那个，分别进一步计算：not（）伪类中的选择器。

如果您要实施选择器3 ，它们不应该被计数在。如前所述，根据该规范，两个选择器都是无效的，因为它只定义：not（）来同时接受一个简单的选择器。

如果您展开它们，以便它们验证（按照这里），那么它们的特性将计算如下：

  / * 2属性，1类，1类型 - > specific = 0-3-1 * / 
 input：not（[type =text]）：not（[type =password]）：not（.someClass）
 
 / * 
 * 1 ID，1 type  - >特殊性= 1-0-1 
 * 1属性，1类型 - > specific = 0-1-1 
 * / 
输入：not（#someId），input：not（[type =text]）
  pre> 
 
 
因为选择器3说：
 
 
否定伪类中的选择器计数与任何其他类似，但否定本身不计为伪-class。
 
 
此外，为了回应您的评论：
 
 
 True，根据规范，只有简单的选择器。但有些浏览器支持多个。有些人没有，有些人后来放弃了。此外，你可以编写相同的规则，即使使用这样的简单选择器： input：not（[type =text]）：not（[type =password]）：not（.someClass ）这是更好的工作，以及。这是否意味着它应该计算为0031，然后？ 
 
 
我知道的只有的浏览器已经支持中的多个选择器：not（）是Firefox 3.0，它是由于一个错误。选择器3 从不允许：not（）包含多个选择器 - 仅在选择器4 ，其特异性计算尚未明确定义 1 ，因此即使您尝试要实现选择器4（我非常怀疑你是），你会被困住。
 
 
 
 我不清楚Firefox 3.0使用其版本的：not（）选择器实现了特殊性，我没有要测试的副本，但我认为它是安全的因为它从来不是预期的行为反正。确定，所以我选择了Firefox 3.0 beta 1，3.0.0，3.0.18和3.1 beta 1，并没有一个重现这种行为。 
 
 
 
 
 
 
  1  请注意，和2011 FPWD是一致的说，：not（）的特殊性等于其最具体的参数，但这可能会在将来改变。 
 
I already know how to calculate selector specificity for CSS (the a/b/c/d mentioned in specs). However, I am having trouble figuring how to calculate it for the :not() pseudo-class. See the following example:
input:not([type="text"],[type="password"],.someClass) {...}
input:not(#someId[type="text"]) {...}
Assuming both of them apply to one element, should these two be calculated as (0011) and therefore they should be ordered according to order of appearance? Or should the selectors inside the :not() pseudo-class be further calculated separately, depending on which one matches, as a second step to determine the one that has precedence over the other?
解决方案

  
Assuming both of them apply to one element, should these two be calculated as (0011) and therefore they should be ordered according to order of appearance? Or should the selectors inside the :not() pseudo-class be further calculated separately depending on which one match as a second step to determine the one that have precedence over the other?
If you're implementing Selectors 3, they should not be counted at all. As already mentioned, both of your selectors are invalid according to that spec because it only defines :not() to accept a single simple selector at a time.

If you expand them out so that they validate (following the instructions/examples given here), then their specificities will be calculated as follows:
/* 2 attributes, 1 class, 1 type -> specificity = 0-3-1 */
input:not([type="text"]):not([type="password"]):not(.someClass)

/* 
 * 1 ID, 1 type        -> specificity = 1-0-1
 * 1 attribute, 1 type -> specificity = 0-1-1
 */
input:not(#someId), input:not([type="text"])
Because Selectors 3 says:

  
Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class.
Also, in response to your comment:

  
True, according to specs, simple selectors only. But some browsers support multiple ones. Some of them don't, and some dropped them later. Also, you can write the same rule even with simple selectors like this instead: input:not([type="text"]):not([type="password"]):not(.someClass) which is better and work as well. Does this mean it should be calculated as 0031, then? How about those that support multiple ones, how do they calculate?
The only browser I know of that has ever supported multiple selectors within :not() is Firefox 3.0, and it does so because of a bug. Selectors 3 never allowed :not() to contain multiple selectors — that is only introduced in Selectors 4, for which specificity calculation hasn't even been clearly defined yet1, so even if you were trying to implement Selectors 4 (which I seriously doubt you are), you'll be stuck.

It's not clear to me how Firefox 3.0 implemented specificity with its version of the :not() selector and I don't have a copy of it to test with, but I think it's safe to assume that it doesn't matter anymore as it was never the intended behavior anyway. OK so I picked up Firefox 3.0 beta 1, 3.0.0, 3.0.18 and 3.1 beta 1, and none of them reproduce this behavior at all. So there you have it.



1 Note that both the current 2013 ED and the 2011 FPWD are consistent in saying that the specificity of :not() is equal to that of its most specific argument, but this may change in the future.

                        
这篇关于计算CSS选择器专用性for：not（）伪类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！