何时添加类,何时添加选择器?

时间:2009-11-17 12:38:32

标签: html css

鉴于此:

<a class="details" href="#">more&hellip;</a>
...
<input type="submit" value="Gogogo">

假设两者都应该具有非常相似的外观,因为这是设计师想要的。你这样做:

<a class="fancybutton" ...
<input class="fancybutton" ...

.fancybutton { /* ... */ }

还是这个?

a.details, .someform input[type="submit"] { /* ... */ }

我正在努力解决这个问题,我不确定该去哪里。它似乎是一个选择,有一个非常清晰的样式表与不满足于类的好标记。

你什么时候选择其中一个?

5 个答案:

答案 0 :(得分:5)

选择类而不是更多花哨的CSS选择器的主要原因是兼容性。仍在使用的至少一个主要浏览器的几个版本不能正确支持更高级的选择器,因此实际上使用类不那么痛苦,因为它们“只是工作”。

答案 1 :(得分:1)

IE6不支持input[type=submit],所以如果我正在为它开发,我肯定会去上课。

答案 2 :(得分:0)

我通常使用类,因为它比浏览器中的属性选择器具有更广泛的支持。在绝大多数人口拥有支持CSS属性选择器的浏览器之前,我会继续在这种情况下使用类。

答案 3 :(得分:0)

我会说,在投诉浏览器中,答案是特异性的。查看样式应用的广度,并将其定义为具有足够的特异性,以便在您的Web应用程序范围内明确无误。

另外,不要害怕在元素上使用多于​​1个样式类来开发分层表示方法,即class =“blackborder smalltext centered”。

答案 4 :(得分:0)

与其他用户一样,使用类很好,因为它确实简化了浏览器兼容性的问题(当你尝试使用花哨的CSS 2选择器时会出现问题)。

在复杂的CSS 2选择器上使用简单的基于类(或基于id,如果可能)选择器的另一个重要原因是速度。

来自谷歌"Optimize browser rendering",您应该尝试使用简单选择器的原因的描述(仅限类/仅限ID的选择器非常简单):

后代选择器是低效的,因为对于与键匹配的每个元素,浏览器还必须遍历DOM树,评估每个祖先元素,直到找到匹配或到达根元素。密钥越不具体,需要评估的节点数就越多。
子选项和相邻选择器效率低下,因为对于每个匹配元素,浏览器必须评估另一个节点。对于规则中的每个子选择器来说,它变得非常昂贵。同样,密钥越不具体,需要评估的节点数就越多。然而,虽然效率低,但在性能方面它们仍然优于后代选择器。

关于来自同一篇文章的后代选择器的类选择器的特定说明:

使用类选择器而不是后代选择器。

例如,如果您对有序列表项和有序列表项需要两种不同的样式,而不是使用两个规则:

ul li {color: blue;}
ol li {color: red;}
    

您可以将样式编码为两个类名,并在规则中使用它们; e.g:

.unordered-list-item {color: blue;}
.ordered-list-item {color: red;}

如果必须使用后代选择器,则首选子选择器,至少只需要评估一个额外节点,而不是所有中间节点直到祖先。