css高级学习选择器

当我第一次开始写css的时候，它代码中的高度自由总是让我困惑。也就是说，如果同一个设计由不同的人实现，那么最终的代码肯定是不同的。但是，有一个问题。如果不同的人通过不同的方法和代码风格在外观上实现相同的设计，将很难评估谁做得更好。我也这么认为。现在设计实现了，目的也达到了，在css这个没有程序逻辑的代码里，能找到什么来说明谁做得更好呢？

现在，我同意css这种描述性语言仍然具有代码质量判断的观点。评判标准是可维护性和性能。通俗地说，一个好的css应该对开发者和浏览器友好。本文将从css选择器的角度解释如何提高css代码的质量。

按键选择器与浏览器样式规则的匹配原则

css选择器的概念，也是在css priority for初学者的开头提到的，指的是每个样式规则中描述要对哪些元素应用样式的部分，也就是{}之前的部分。本文引入了一个额外的概念：键选择器。键选择器是每个样式规则开始之前的最后一个选择器，如下图所示：

Css选择器将决定下列属性定义适用于哪些元素，因此浏览器根据css选择器将样式应用于相应的元素有一个匹配过程。关于浏览器风格匹配系统，David Hyatt在编写用于Mozilla ui的高效CSS时提到了以下内容：

样式系统通过从最右边的选择器开始并通过规则的选择器向左移动来匹配规则。只要您的小子树继续检出，样式系统将继续向左移动，直到它匹配规则或因不匹配而退出。

这意味着浏览器引擎从右向左执行样式匹配。当某个样式规则被特别匹配时，这个从右到左的过程将继续，直到整个选择器序列被读取和匹配，或者由于某个地方的不匹配而被取消(然后转移到另一个样式规则)。

至于浏览器为什么选择这个匹配顺序，可以看看关于栈溢出的讨论。粗略解释一下，由于最右边的键选择器直接表示样式定义应该应用到的元素，从右到左的顺序更有利于浏览器在初始匹配时确定具有样式定义的元素集，也避免了大多数选择器在更快地寻找元素样式时实际上没有应用。

更好的css选择器是让浏览器在样式匹配的过程中减少匹配查询的次数，以更快的速度完成样式匹配，从而优化前端性能。其中，从右到左的样式还必须参考浏览器的匹配顺序。

css选择器的正确使用更加具体

更具体的键选择器

键选择器是浏览器引擎在匹配样式时读取的第一部分。因此，如果在某个样式规则中使用更具体、更具体的选择器，可以帮助减少浏览器的搜索次数和匹配次数。

例如，以下选择器：

的最后一段时间。内容。note span{}是键选择器，标签span广泛应用于网页中。当浏览器从span中读取选择器时，它可能会在样式匹配方面做一些额外的工作。

如果您确定只想定义span元素在哪个位置的样式，那么最好将span类命名为span.note_text，然后简单地写成：note_text{}使用类别选择器

类选择器(Class selector)是最有利于性能优化的选择器。与类相比，ID的缺点是只能定义到一个元素，不能重用。此外，没有什么比类更好的用途了。很多时候，很难确定一个元素是否唯一。此外，使用类来定义样式并为javascript保留ID总是一个很好的做法。如果可能，不要使用标识来定义样式。

与类相比，标签在html中更具重复性，因此浏览器也有可能在样式匹配方面做更多额外的工作。如果可能，除了css样式重置之外，不使用标签选择器(也称为元素选择器)。

缩短选择器序列

继承编写(准确地说，css关系选择器中的包含选择器)是css中常见的编写。继承编写的初衷是，如果有两个标签相同或者类名相同的元素，将父元素的选择器相加形成选择器序列，可以避免两个元素的样式在不需要的时候互相影响。例如，确认层。submit_btn表示样式应用于类名为submit_btn的元素，该元素的父元素的类名为confirm_layer。

但是，避免元素样式的影响并不意味着可以随意使用继承选择器。如前所述，浏览器将从右向左读取整个选择器序列，直到它被读取和匹配，或者由于不匹配而被取消。因此，较短的选择器序列更有利于浏览器更快地完成匹配过程。相比之下，冗长的选择器序列被认为是低效的，例如：标题ul li。nav_link{}建议写：标题。nav_link{}一般来说，不超过三个继承级别就能满足实际开发需求。因此，应该减少不必要的继承级别，并使用更短的选择器序列。

此外，较长的选择器序列也有问题。对于选择器较长的样式规则，css优先级的计算值也较大。因此，如果将来需要编写新的样式来覆盖它，就需要编写更长的选择器(或者使用ID)来获得更高的css优先级。这对性能和代码可读性都是有害的。

避免链选择器

链接选择器是同时为单个元素编写多个选择器的情况。例如，p.name指的是类名为name，标签为p的元素，然后应用样式。这些决策组合可以是标识选择器、标签选择器和类选择器的任意组合。

但是，链选择器过度限定，不利于重用和性能优化。如：

推荐#作者{}:

#作者{} A这里没有必要。一个ID只对应一个元素，所以不需要强调这个元素的标签是什么(类似的，class也不是必须的)。还有。建议将content span.arrow{}写成：内容。箭头{}跨度中的跨度。这里的箭头也是不必要的。一方面，这在样式匹配中给浏览器增加了一个额外的任务：检查类名为arrow的元素的标记名是否是span，这会降低性能。另一方面，如果删除此限制，则。arrow可以用在更多的元素上，它有更好的可重用性。否则，你必须告诉其他人你只能在span标签上使用这个。

同样，多类的链式书写，如。tips .魅惑{}建议更改命名，并将其写成：tips _魅惑{}这可以帮助浏览器减少额外的样式匹配工作。

此外，IE6还存在链选择器问题。当多个类选择器一起编写时，例如class1.class2.class3，通常只有当类的所有元素同时存在时，才应用该样式。但是，IE6只识别最后一个，即符合的选择器的元素。类3，并应用该样式。

例外

上述编写选择器的建议只是从浏览器渲染性能优化和代码可重用性方面的理论结果。在实际使用中，不需要严格遵循这些内容。例如，如果你真的要在一个类名为intro的元素中给所有的A标签元素添加一个特定的样式，那么像。intro a是明智的。

结论

关于高效css选择器的指南，你也可以在google developer中阅读使用高效CSS选择器。

如今，现代浏览器在样式匹配方面逐渐得到了更多的优化(参考CSS选择器性能发生了变化！)，有些方面的内容我们不再需要担心。然而，这并不意味着您不需要考虑编写合理的css选择器。css选择器的性能优化仍然存在，您的选择器应该更好地反映您的意图，而不是随意使用它们。更重要的是，用这样一个略显微妙和深思熟虑的想法来编写css选择器并不难。只要你想养成这样的习惯，自然可以在这方面做得更好。为什么不呢？

以上就是本文的全部内容。希望对大家的学习有帮助，支持我们。