後代選擇器很慢？

當我讀了更快的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

後代選擇器很慢？

回答

相關問題