CSS选择器的优先级

MDN上关于CSS选择器优先级的介绍

https://developer.mozilla.org/zh-CN/docs/Web/CSS/Specificity

ID、class、元素 、属性

优先级排名为：

1. ID[属性][伪类]
2. ID[属性] --或-- ID[伪类]; 看声明顺序, 后声明的优先级更大
3. ID
4. class[属性][伪类]
5. 元素[属性][伪类]
6. class[伪类] --或-- class[属性]; 看声明顺序，后声明的优先级更大
7. 元素[伪类] --或-- 元素[属性]; 看声明顺序，后声明的优先级更大
8. class
9. 元素

Chrome的实测图

为了便于记忆，我总结了如下规律，将它们转化为数字的加法

1. ID – 1000
2. class – 450
3. 元素 – 400
4. 属性 – 100
5. 伪类 – 100

最后，就可以将之转化为如下的数字，以后也不用单独去记忆，用的时候做做加法就行了。

1. ID[属性][伪类]； 1000 + 100 + 100 = 1200
2. ID[属性] --或-- ID[伪类]; 看声明顺序, 后声明的优先级更大 ； 1000 + 100 = 1100；
3. ID ；1000
4. class[属性][伪类]；450 + 100 + 100 = 650
5. 元素[属性][伪类]；400 + 100 + 100 = 600；
6. class[伪类] --或-- class[属性]; 看声明顺序，后声明的优先级更大；450 + 100 = 450；
7. 元素[伪类] --或-- 元素[属性]; 看声明顺序，后声明的优先级更大；400 + 100 = 500；
8. class；450
9. 元素；400

ID、class、元素 混用

如果是 元素[class]，也就是ID、class、元素混用的情况，这样的选择器的优先级在哪儿呢？

这里我不做研究，因为这个代码写出来后你会发现上面的公式乱掉了，我个人是会尽量避免这种写法的。

这种写法不仅仅让优先级难以捉摸，更让代码不好维护。假若某件维护人修改了HTML代码，但是他并不知道CSS需要修改，就会形成BUG。见下面这个例子

<input type="text" class="test">

input.test {}

修改为

<select class="test"></select>

input.test {} // 这里会形成BUG

如果大家工作有必须有混用的情况，可以基于我的研究之上，再进行研究总结。也可以给我发邮件，我们一起探讨下。

“+”，“~”，“>”，“ ”，“” 选择器的应用

“+”，“~”。优先级看顺序，后声明的优先级更大

综合后的优先级为

1. ID+ID
2. ID[属性]
3. class + ID 或 ID + class ; 看声明顺序
4. ID
5. class[属性]
6. class+class
7. 元素[属性]
8. class
9. 元素

其实还有更复杂的，那就是 ID + ID[属性]、ID + ID[属性][伪类]。再这样研究下去怕是乱成一团了。

当我们想要刻意去使用优先级来维持好网页表现时，就不应该搞得过于复杂，太复杂的代码真的很容易出BUG.

“>”, " " 与 “+”, “~” 同时使用时

优先级为:

1. ID + ID
2. ID ID
3. ID[属性]
4. class + ID 或 ID + class; 看声明的顺序
5. class ID) || (ID class
6. ID 元素
7. ID
8. class[属性]
9. class + class
10. class class
11. 元素[属性]
12. class 元素
13. class
14. 元素

可以看到，这里已经很复杂了，如果我们再把伪类加上去，把“>”选择器加上去，会如何呢？？

我感觉会炸，这么复杂的优先级，单单记住都已经很难了，如果再将之应用于产品中，代码会变了不好维护和迭代了。我选择不用，所以后续的也不做研究了。

感想

平时我们书写CSS代码时，以我为例，常用的选择器是：class、后代、子代、伪类。ID选择器用的都很少，一般只会用来做做鼻祖元素