一、css選擇器的解析順序
相信很多人在一開始接觸css的時候都會看到一條規則就是盡量少使用層級關係，比如盡量不要寫成：
#div
p.class
.class
原因其實很簡單，我們犯了乙個經驗主義錯誤，預設css選擇器是從左往右進行解析的，實際上恰恰相反，css選擇器是從右往左解析的。
二、css選擇器進行優化的必要性
ok，具體的情況具體分析，我們先來看一看瀏覽器的渲染過程，如圖：
在圖中我們可以看到html解析出了一顆dom tree，與此同時樣式指令碼則解析生成了乙個style rules，也可以說是乙個css tree。最後，dom tree同style rules一同結合解析出一顆render tree，而render tree就是包含了乙個dom物件以及為其計算好的樣式規則，提供了布局以及顯示方法。
因為不清楚乙個dom物件上究竟對應著哪些樣式規則，所以只能選擇乙個最笨的辦法，即每乙個dom物件都遍歷一遍style rules，dom物件的數量相信大家也都清楚，如果每次遍歷style rules都是像乙個曬太陽的老大爺一樣的悠哉遊哉，那麼滑鼠廠商應該會很開心，嗯，摔壞了正好買新的嘛~~~因此對css選擇器進行優化就是乙個必須的事情了。
三、從右往左解析到底好在**
假如有如下的一段html：
id="div1">
class="a">
class="b">
...div>
class="c">
class="d">
...div>
class="e">
...div>
div>
div>
class="f">
class="c">
class="d">
...div>
div>
div>
div>和如下的css：
#div1 .c .d {}
.f.c
.d {}
.a.c
.e {}
#div1 .f {}
.c.d{}
首先，#div1 .c .d ｛｝ .f .c .d ｛｝.c .d｛｝這三個選擇器裡面都含有 .c .d｛｝這麼乙個公用樣式，所以哪怕是我們的dom節點明確了是在#div1下面都必須對style rules進行全部的匹配查詢，這樣一來基本上可以說是每乙個dom節點都必須完全遍歷一遍style rules，不然搞不好就會漏掉一些公用樣式之類的，所以想著將層級寫的更加詳細就能去掉很多不對應的css選擇器的索引路徑的就不要想了，不管你寫的多細，你總是需要把整個style rules都遍歷一遍，不然萬一漏掉了某個公用樣式不就思密達了？
那麼如果我們換成從右向左進行解析就能夠避免這種情況了麼？請看下面這個style rules：
別的先不提，最少這個節點就少了很多嘛，哪怕我這裡同樣是需要全部遍歷一遍就衝著減少了這麼多個節點也要從右往左進行解析啊！
更重要的是，只要有公用樣式，那麼選擇器最右邊的那個型別選擇器一定是相同的，如此公共樣式就很自然的都集中到乙個分支上，這個時候我們完全可以將其他不匹配的路徑全部去掉而不用擔心會漏掉某些個公用樣式了。雖然當這顆css樹在遍歷的時候還有有部分節點會遍歷到最後才能確定到底是不是匹配的，但總的來說從右往左進行解析還是會比從左往右解析要少很多次的匹配，這樣帶來的效率提公升是顯而易見的！
同時，這也是不建議使用*萬用字元來進行樣式匹配的原因：瀏覽器專門建立了乙個反常規思維的從右往左的匹配規則就是為了避免對所有元素進行遍歷，你直接乙個萬用字元等於之前的工作都白做了。
為什麼CSS選擇器解析是從右往左匹配？
在平時的開發過程中，我知道css選擇器是從右往左匹配的，但是不知道為什麼是從右往左而不是從左往右。這裡記錄一下分析心得。我們知道dom樹和css會合成為render樹，這個操作實際上就是是需要將css附著到dom樹上，因此需要根據選擇器提供的資訊對dom樹進行遍歷，才能將樣式成功附著到對應的dom元...
CSS解析誤解 選擇器的從右向左解析
對於下面兩種css寫法，相信很多人和我想的一樣 ul.new ul 比 new ul 更高效。其實我們的理解貌似沒有錯。如果在類名前面加上標籤的話，這樣瀏覽器就可以先找到所有對應的標籤，然後匹配類名，這樣就不用全域性匹配了，查詢速度自然會快很多。我們這樣的理解，意味著選擇器解析是從左往右的，就像jq...
CSS復合選擇器是什麼？復合選擇器是如何工作
選擇器 描述舉例 選擇器1 選擇器2 多元素選擇器。同時匹配選擇器1和選擇器2，多個選擇器之間用逗號隔開即可。h1,h2,h3 e f 後代元素選擇器，匹配所有屬於e元素後代的f元素，e和f之間用空格隔開即可。box h1 e f 子元素選擇器，匹配所有e元素的子元素為f div h1 e f相鄰元...