https://segmentfault.com/q/1010000000713509
CSS 的后代選擇器本身就是一種在標准里面不那么推薦的方式。
首先，對瀏覽器來說，ID 選擇器
#xx是最快的，其次是 class 選擇器、html 元素選擇器等。
那為什么從右向左的規則要比從左向右的高效？
如圖：
假如 DOM 的結構如上圖，匹配規則是 .mod-nav h3 span。
若從左向右的匹配，過程是：從 .mod-nav 開始，遍歷子節點 header 和子節點 div，然后各自向子節點遍歷。在右側 div 的分支中，最后遍歷到葉子節點 a ，發現不符合規則，需要回溯到 ul 節點，再遍歷下一個 li-a，假如有 1000 個 li，則這 1000 次的遍歷與回溯會損失很多性能。
再看看從右至左的匹配：先找到所有的最右節點 span，對於每一個 span，向上尋找節點 h3，由 h3再向上尋找 class="mod-nav" 的節點，最后找到根元素 html 則結束這個分支的遍歷。
很明顯，兩種匹配規則的性能差別很大。之所以會差別很大，是因為從右向左的匹配在第一步就篩選掉了大量的不符合條件的最右節點（葉子節點）；而從左向右的匹配規則的性能都浪費在了失敗的查找上面。
當然這是比較明顯情況，如果在葉子上存在多個不符合條件的 span，從右向左的規則也會走一些彎路（這時就需要優化 CSS 選擇器了）。但平均來說它還是更高效，因為大多時候，一個 DOM 樹中，符合匹配條件的節點（如 .mod-nav h3 span）遠少於不符合條件的節點。
此段轉載自：http://www.cnblogs.com/zhaodongyu/p/3341080.html 經過編輯及排版。
但是后來人們發現這種方式很不符合人類自然的思考方式，所以在建造 web 的時候更喜歡采用看起來比較有條理的更加像后端程序的層次結構方式命名，類似 #fuck .you a {...}。
但是根據實踐，大家發現這樣基本是在 自high，因為別人在改 CSS 的時候是不會去看你寫的 CSS 的，都是直接瀏覽器定位到位於哪一行，直接過去改代碼塊，反正一眼就能看懂。
其實不用糾結這些，CSS 的解析時間跟 js 執行時間相比就像 PHP 代碼的運行時間和數據庫、I/O運行時間對比一樣，不是一個數量級，完全不用擔心。