### 如何編寫高效的 CSS 選擇符
2017-04-24
大部分人看到下面的這一小段 CSS 代碼:
```
#menus > li { font-size: 14px; }
```
可能都會猜想瀏覽器會使從左到右匹配上面的規則,我們會想象瀏覽器先找到唯一的 id 為 menus 的元素,然后把樣式應用到其直系子元素 li 元素上。這看起來好像還挺高效的。
但是,事實上,CSS 選擇符是從右到左進行匹配的。所以,上面的這條規則并不高效,瀏覽器必需遍歷頁面上的每個 li 元素并確定其父元素的 id 是否為 menus。
樣式系統從最右邊的選擇符開始向左匹配規則。只有當前選擇符的左邊還有其他的選擇符,樣式系統就會繼續向左移動,直到找到和規則匹配的元素,或者因為不匹配而退出。 —- 《在 Mozilla UI 中編寫高效的 CSS》 David Hyatt
以下是 David Hyatt 在書中提出的編寫高效選擇符指南:
一、避免使用通配規則
除了傳統意義上的通配選擇符之外,我們把相鄰兄弟選擇符、子選擇符、后代選擇符合屬性選擇符都歸納到通配規則分類下,推薦僅使用 ID、類和標簽選擇符。
二、不要限定 ID 選擇符
在頁面中一個指定的ID只能對應一個元素,所以沒有必要添加額外的限定符。例如,div#header是沒有必要的,應該簡化為#header。
三、不要限定類選擇符
不要用具體的標簽限定類選擇符,而是根據實際情況對類名進行擴展。例如,把li.chapter改成.li-chapter,或是.list-chapter更好。
四、讓規則越具體越好
不要試圖編寫像 ol li a 這樣的長選擇符,最好是創建一個像.list-anchor一樣的類,并把它添加到適當的元素上。
五、避免使用后代選擇符
通常處理后代選擇符的開銷時最高的,而使用子選擇符也可以得到想要的結果,并且更加高效。
六、避免使用標簽—子選擇符
如果有像#menus > li > a這樣的基于標簽的子選擇符,那么應該使用一個類來關聯每個標簽元素,例如.menus-item。
七、質疑子選擇符的所有用途
檢查所有使用子選擇符的地方,然后盡可能用具體的類取代它們。
八、依靠繼承
了解哪些屬性可以通過繼承而來,然后避免對這些屬性重復指定規則。例如,對列表元素而不是每個列表元素指定list-style-image。請參考繼承屬性的列表來了解每個元素的可繼承的屬性。
摘自《高性能網站建設進階指南——Web開發者性能優化最佳實踐》
來源: http://hejx.space/2017/04/24/高效CSS選擇器/
* * * * *
### 其他
[是什么阻礙了代碼的重用?問題是否應該只解決一次即可? - 知乎](https://www.zhihu.com/question/21011591)
>[danger] **重用是有代價的,不要為了重用而重用,忘記我們的來處,我們是要解決問題的。** 沒有人規定一個代碼寫出來必須要是重用的,不要覺得為了一個效果寫出來的代碼,只是一個地方用到了而已,沒有被重用就很可惜,就很浪費,這種觀點是錯誤的。不要被自己所束縛。
幾乎每個人都會認為自己寫的東西很棒,是最好的,其實并不是這樣的,寫出好的代碼不是件容易的事情。我們最大的敵人是我們自己。
[我們要寫真正的CSS!](http://mp.weixin.qq.com/s/a2aA7uOlEb6hhLTw7xu4eQ)
[精通 CSS 選擇器 - by.Genesis - 博客園](http://www.cnblogs.com/xyzhanjiang/p/5447406.html)
[精通 CSS 選擇器(二) - by.Genesis - 博客園](https://www.cnblogs.com/xyzhanjiang/p/5570726.html)
[不可不看!CSS3中三十一種選擇器用法 - Ranran - 博客園](https://www.cnblogs.com/ranran/p/31_css3_selector.html)
[神奇的選擇器 :focus-within](https://mp.weixin.qq.com/s/q-OaYqJfm08803-E5PJOhA)
> 偽類和偽元素的區別
[Facebook 重構:拋棄 Sass / Less ,迎接原子化 CSS 時代](https://juejin.cn/post/6917073600474415117)
* * * * *
last update:2018-5-17 16:54:54
- 開始
- 微信小程序
- 獲取用戶信息
- 記錄
- HTML
- HTML5
- 文檔根節點
- 你真的了解script標簽嗎?
- 文檔結構
- 已經落后的技術
- form表單
- html實體
- CSS
- css優先級 & 設計模式
- 如何編寫高效的 CSS 選擇符
- 筆記
- 小計
- flex布局
- 細節體驗
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物語
- js函數定義
- js中的數組對象
- js的json解析
- js中數組的操作
- js事件冒泡
- js中的判斷
- js語句聲明會提前
- cookie操作
- 關于javascript你要知道的
- 關于innerHTML的試驗
- js引擎與GUI引擎是互斥的
- 如何安全的修改對象
- 當渲染引擎遇上強迫癥
- 不要使用連相等
- 修改數組-對象
- 算法-函數
- 事件探析
- 事件循環
- js事件循環中的上下文和作用域的經典問題
- Promise
- 最佳實踐
- 頁面遮罩加載效果
- 網站靜態文件之思考
- 圖片加載問題
- 路由及轉場解決方案
- web app
- 寫一個頁面路由轉場的管理工具
- 談編程
- 技術/思想的斗爭
- 前端技術選型分析
- 我想放點html模板代碼
- 開發自適應網頁
- 后臺前端項目的開發
- 網站PC版和移動版的模板方案
- 前后端分離
- 淘寶前后端分離
- 前后端分離的思考與實踐(一)
- 前后端分離的思考與實踐(二)
- 前后端分離的思考與實踐(三)
- 前后端分離的思考與實踐(四)
- 前后端分離的思考與實踐(五)
- 前后端分離的思考與實踐(六)
- 動畫
- 開發小技巧
- Axios
- 屏幕適配
- 理論基礎
- 思考
- flexible.js原理
- 實驗
- rem的坑,為什么要設置成百分比,為什么又是62.5%
- 為什么以一個標準適配的,其它寬度也能同等適配
- 自適應、響應式、彈性布局、屏幕適配
- 適配:都用百分比?
- 番外篇
- 給你看看0.5px長什么樣?
- 用事實證明viewport scale縮放不會改變rem元素的大小
- 為什么PC端頁面縮放不會影響rem元素
- 究竟以哪個為設備獨立像素
- PC到移動端初試
- 深入理解px
- 響應式之柵格系統
- 深入理解px(二)
- 一篇搞定移動端適配
- flex版柵格布局
- 其他
- 瀏覽器加載初探
- 警惕你的開發工具
- JS模塊化
- webpack
- 打包原理
- 異步加載
- gulp
- 命名規范
- 接口開發
- sea.js學習
- require.js學習
- react學習
- react筆記
- vue學習
- vue3
- 工具、技巧
- 臨時筆記
- 怎么維護好開源項目
- 待辦
- 對前端MVV*C框架的思考
- jquery問題
- 臨時
- 好文
- 節流防抖