大家好，我是小雨小雨，致力於分享有趣的、實用的技術文章。
內容分為翻譯和原創，如果有問題，歡迎隨時評論或私信，希望和大家一起進步。
大家的支援是我創作的動力。

選擇器的優先順序

眾所周知，選擇器是有權重的，優先順序從低到高，如下所示：

• 型別選擇器（例如，h1）和偽元素（例如，::before）
• 類選擇器 (例如，.example)，屬性選擇器（例如，[type="radio"]）和偽類（例如，:hover）
• ID 選擇器（例如，#example）
• !important 此宣告將覆蓋任何其他宣告，不建議使用，除非以下幾種情況：

1. 覆蓋內聯樣式
2. 覆蓋優先順序絕對高的選擇器

選擇器解析

雖然我們平常寫css選擇器是從左到右書寫的：

根節點 .子節點 .孫節點{

}

但是，這只不過是為了方便使用者書寫，真正的解析順序是反過來的，也就是從子節點搜尋到根節點，原因很簡單，因為查詢次數將大大影響效率。一個個來說

由於css tree是樹結構，如果從根節點開始，那麼就是類似深度優先遍歷的查詢方式，一圖闢千言：

如果到最後一個子節點仍然找不到的話，就是回到之前的父節點，繼續查詢其他的子節點，其實看起來也沒毛病哈，那我們來個對比，看下css為什麼選擇從左到右解析。

一樣的圖，換了個解析方向：

很明顯的差別就是，我們的判斷條件提前了，先判斷孫節點是否匹配，只有匹配才會繼續深入，否則直接跳過，然後這就從多個多條線（深度優先遍歷）變成了多個單條線的問題，有點類似於從O(n2) => O(n)的意思，大大提高了元素匹配效率。

大白話解釋就是： 從右到左解析比從左到右解析減少了查詢失敗的次數和深度

還有一點就是公共樣式，對於公共樣式，其實就是多個相同的樣式，從子節點到根節點是完全相同的，也就是一條線即可

書寫高效css選擇器

• 優先就是避免使用萬用字元匹配，這樣css從右到左的解析就白搭了，莫得用處了。就和從左到右一樣一樣的了。
• 之前提到的選擇器優先順序ID選擇器是最高的，但這僅僅限於單獨用ID選擇器，如果你和其他選擇器混合使用的話，就發揮不到id選擇器的唯一高效性了。為什麼呢？因為從右到左解析呀，比如 #box .text，會先進行類選擇器的查詢，最後才是ID選擇器，所以ID選擇器就顯的沒那麼重要了。
• 儘量少使用標籤結束，因為這會讓瀏覽器查詢很多個子節點，然後才能確定是否匹配，比如：.box a
  ，只要有a標籤就會進行查詢，但是其實我們只想給.box上的a設定樣式，我們可以給個更具體的類選擇器：.box .href，這樣就能匹配更少的元素啦
• 還有就是經常說的避免選擇器超過三個，比如 .div1 .div2 .div3 .p .a 就可以優化為 .div1 .a，為啥這樣說的，因為查詢中也有條件進行判斷啊我們提供了一個子節點.a，並且是在.div1下的其實就夠了，他會沿著一條線查詢，知道跟節點，咱寫這麼多選擇器只會徒增判斷條件，沒卵用。。
• 還有就是儘量寫得具體，可以使用>操作符等等
• 選擇器上能縮寫的命名就儘量縮寫、相同父層級的選擇器合併，都可以適當減少css體積。
• 使用CSS BEM書寫規範
• 歡迎補充

最後

這次分享內容就到這了，比較短小，哈哈。

打算做完rollup之後，重拾基礎了，畢竟一切都是從根本一點點碼起來的，只有底子厚了，才能厚積薄發。

相關推薦