假設最後一個css元素是html標籤，則選擇器解析從左往右的提案

時間 2019-12-04

標籤假設最後一個 css 元素 html 標籤選擇器解析從左往右提案欄目 CSS 简体版

原文原文鏈接

現狀

如今瀏覽器css匹配核心算法的規則都是是以 right-to-left 方式匹配節點的。css

如.root .sub span {...}，瀏覽器渲染方式是 span -> .sub -> .root
它的讀取順序變成：先找到全部的span，沿着span的父元素查找.sub,再找.root，中途找到了符合匹配規則的節點就加入結果集；若是直到根元素html都沒有匹配，則再也不遍歷這條路徑，從下一個span開始重複這個過程。html

舉例

若是整個html只有一個span標籤，那 right-to-left 方式的確是最快的，可是每每大部分網頁都不僅一個span標籤，多個span標籤將會有不少無效的匹配，那這時是否是 left-to-right 會更好一點。git

案例：github

<html>
  <div class="root">
    <div class="sub"><span>1</span></div>
  </div>
  <div>
    <div><span>2</span></div>
  </div>
  <div>
    <span>3</span>
  </div>
  <span>4</span>
</html>

.root .sub span {}

right-to-left 解析
先找到全部的最右節點 span，有4個，對於每個 span，向上尋找節點發現不是.sub,在查找上上節點，直到找到html，發現沒有符合的。再從下一個span開始重複這個過程。
上面狀況有4個span至少有4個分支的往上遍歷。假若有 1000 個不在.sub中的span，就有 1000 次的分支遍歷，而符合條件的只有1個，會損失不少性能。算法

left-to-right 解析
從 .root 開始,遍歷全部子節點，若是沒有找到.sub，回溯到上個節點接着遍歷，直到找到.sub，再遍歷.sub下的子節點找到span結束。
上面狀況1次就能找到符合條件的span。瀏覽器

上面案例明顯 left-to-right 比 right-to-left 解析效率更高。app

固然也有狀況是，若是.root下面有不少複雜子節點，須要遍歷與回溯不少次，而.root外的span很少，則 right-to-left 解析效率更高。dom

提案

大部分書寫習慣是不想每一個html標籤都加class name，能夠用不一樣html標籤選擇出來的。以下所示：性能

<div>
  <div id="sub">
    <span>1</span><label>2</label><div>3</div>
  </div>
  ...  <!-- 裏面有不少span，label，div標籤 -->
</div>

#sub span{}
#sub label{}
#sub>div{}

先找到#sub再找html標籤的話，css解析效率會高些。
那麼 left-to-right 比 right-to-left 解析效率高。
因此提案以下：ui

假設最後一個css元素是html標籤，而父元素有ID或Class選擇器時，則選擇器解析從左往右的，其餘狀況仍是從右往左。

Ps：這裏本妹子的一個想法，歡迎各位小夥伴們一塊兒討論，若是大部分都以爲有道理的話，我想試着向 w3c組織提出建議需求。

其餘連接

原文地址：https://raoenhui.github.io/css/2019/03/30/left-to-right

Happy coding .. :)

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。