后代选择器很慢？

当我读了更快的css选择器，我有通知IDs和Classes比任何其他更快。此外，浏览器与您的CSS Selectors相匹配右到左。也就是说，首先选择最具体的选择器。后代选择器很慢？

所以作者说不要附加任何后代的类;标识。

然而，当我读Facebook和Twitter的源代码，我发现他们使用CSS是这样的：.uiInfoTable .label .annotation{color:#999}'，.big-photo-permalink .tweet .tweet-timestamp{// some css}

当这些选择是缓慢的，他们为什么不干脆用.annotation{color:#999}代替这样长的选择器，或者如果这个类对两个标签都可用，那么为什么不创建一个新类并添加这些CSS？

有什么我应该知道的后代选择器？它们对CSS选择器的性能有影响吗？

来源

2014-04-02 user3205479

因为不是每个人都遵循每个指导方针吗？我个人认为整个“永不使用后代选择器”的东西毫无根据。如果你需要避免后代选择器，你会遇到更大的问题，因为它们实际上会减慢页面的速度。 – BoltClock

@BoltClock但每个人都遵循我猜测的表现？如果他们不担心人们停止使用它的速度？ – user3205479

@BoltClock如果我避免了descedant选择器它会减慢页面？你能否详细解释我或者帮助我找到答案的教程。非常感谢任何帮助 – user3205479

在大多数情况下，性能命中几乎为零。但是，如果你开始构建更复杂的样式表，那么“几乎为零”可以加起来相当大的东西。

就我个人而言，我喜欢在任何时候都可以使用>组合器。例如，.menu>li比.menu li更好，因为引擎只需查找一个级别，而不是每次都进入顶部。

>的另一个优点是它有明确的定义。想象一下：

<ul class="nav"> 
    <li>Item 1</li> 
    <li>Item 2</li> 
    <li>Item with submenu 
     <ul> 
      <li>Item 3.1</li> 
      <li>Item 3.2</li. 
     </ul> 
    </li> 
</ul>

现在让我们假设你想将样式应用于<li> S，但不子菜单。 .nav>li的作品非常漂亮，而.nav li也会设计子菜单。一个无知的程序员可能会试图用.nav li li覆盖它，使性能问题变得更糟。

来源

2014-04-02 13:27:17

后代选择器很慢？

回答

相关问题