CSS規(guī)范并沒有明確瀏覽器如何去實現(xiàn)樣式系統(tǒng)，僅僅是說明了它們必須這樣做。有鑒于此，不同的樣式系統(tǒng)引擎可能會擁有完全不同的表現(xiàn)和行為，特別是 Gecko 與 WebKit， 這兩個引擎都是開源項目，實現(xiàn)了類似的算法，具有極其相近的優(yōu)缺點。因此下面介紹的小技巧對于真實世界的 Web 文檔將會十分有用。

第一部分內(nèi)容綜合討論了常見的樣式系統(tǒng)是如何分類規(guī)則的。接下來的部分包含了書寫規(guī)則的指南，它利用了前面討論的樣式系統(tǒng)的優(yōu)點。

樣式系統(tǒng)如何拆分規(guī)則

樣式系統(tǒng)將規(guī)則拆分成四個主要類別：

1.ID 規(guī)則
2.Class 規(guī)則
3.標簽規(guī)則
4.通用規(guī)則
理解這些分類是十分關(guān)鍵的，因為它們是構(gòu)建規(guī)則匹配塊的基礎(chǔ)。

我在下面的段落中使用術(shù)語 關(guān)鍵選擇器（key selector）。選擇器的最后面的部分即為關(guān)鍵選擇器（即用來匹配目標元素的那部分，而不是該元素的祖先元素）。

例如，在下面規(guī)則中…

關(guān)鍵選擇器為 img、 p 和 title.

ID 規(guī)則

這第一個類別包含了那些將 ID 選擇器作為關(guān)鍵選擇器的規(guī)則。

示例

Class 規(guī)則

如果一個規(guī)則將一個 class 明確作為它的關(guān)鍵選擇器，那么它就屬于該類別。

示例

標簽規(guī)則

如果既沒有 class 也沒有 ID 來明確作為關(guān)鍵選擇器，那么接下來的候選者就是 標簽 類別。 如果一條規(guī)則將一個標簽作為它的關(guān)鍵選擇器，那么這條規(guī)則就屬于該類別。

示例

通用規(guī)則

不屬于上面那些類別的規(guī)則都屬于這個類別。

示例

樣式系統(tǒng)如何匹配規(guī)則

樣式系統(tǒng)從關(guān)鍵選擇器開始匹配規(guī)則，然后左移（查找規(guī)則選擇器的任何祖先元素）。只要選擇器的子樹（substree）一直在檢查，樣式系統(tǒng)就會持續(xù)左移，直到和規(guī)則匹配，或者是因為不匹配而放棄該條規(guī)則。

規(guī)則過濾是你需要學習的最基礎(chǔ)的概念。分類存在的意義就是過濾掉無關(guān)的規(guī)則（這樣樣式系統(tǒng)就不會浪費時間去匹配它們了）。

這就是能夠極大提高性能的關(guān)鍵。對于一個給定的元素，需要匹配的規(guī)則越少，樣式的解析就會越快。

舉個例子，如果一個元素擁有一個 ID，那么只有匹配該 ID 的 ID 規(guī)則才會被選中。同理，只有當 Class 規(guī)則中的 class 出現(xiàn)在元素上時該規(guī)則才被檢查。只有當標簽規(guī)則的標簽匹配時該規(guī)則才被檢查。通用規(guī)則始終都會檢查。

高效 CSS 指南

避免通用規(guī)則

請確保規(guī)則不以通用類型選擇器作為結(jié)束！

不要用標簽名或 classes 來限定 ID 規(guī)則

如果規(guī)則擁有 ID 選擇器作為其關(guān)鍵選擇器，則不要為規(guī)則增加標簽名。因為 ID 是唯一的，增加標簽只會沒必要地減緩匹配過程。

差

差

好

好

例外：在不同的場景下，要動態(tài)改變元素的class，從而應(yīng)用不同的樣式，這是可取的。但是這個相同的class是與其他元素所共享的。
不要用標簽名限定 class 規(guī)則

前面那節(jié)內(nèi)容在這里同樣適用。雖然在同一頁面能夠多次使用 class，但它仍然比標簽名更獨特。

按照慣例，你可以將標簽名包含在 class 名里。但是，這會有損靈活性；如果設(shè)計更改以至于要變更標簽，這條class 名也必須跟著變動。（最好的辦法是選擇嚴格語義化的名字，畢竟分離樣式表的一個目標就是為了靈活性。）

差

好

棒

盡量使用最具體的類別

解析速度變慢的罪魁禍首就是標簽類別中有過多的規(guī)則。通過增加 class 到元素上，我們就可以進一步的將這些規(guī)則劃分到 Class 類別中，這將減少用于匹配標簽的時間。

差

好

避免后代選擇器

后代選擇器是 CSS 中性能耗用最大的選擇器。 它是性能開銷相當大的——特別是當選擇器在標簽或通用類別中。

通常我們需要的是 子選擇器。比如說，當性能十分差的時候，F(xiàn)irefox 的用戶界面CSS 將毫無理由的禁止掉后代選擇器。你也應(yīng)該在網(wǎng)頁中這么做。

差

略好，但還是差（查看下一條指南）

標簽分類的規(guī)則不要包含子選擇器

標簽類別的規(guī)則中避免使用子選擇器。否則的話，在該元素出現(xiàn)的所有地方，匹配時間都將極大延長（特別是當規(guī)則很可能會被匹配）。

差

好

在使用子選擇器的地方想想為什么

當使用子選擇器時要十分謹慎。能免則免。

特別來說，子選擇器常常用于 RDF 樹與菜單：

差

要記住，模板中的 REF 特性可以重復(fù)出現(xiàn)！好好利用這一優(yōu)點。在子 XUL 元素上重復(fù)使用 RDF 屬性，這樣可以基于該屬性來修改元素。

GOOD

依賴繼承

了解哪些屬性能夠繼承，然后允許它們這樣做！

例如，XUL組件會明確的設(shè)置，使得父級元素的列表樣式圖像或字體規(guī)則衍生到匿名內(nèi)容。因而沒有必要去在匿名內(nèi)容上直接應(yīng)用規(guī)則浪費時間。

差

好

在以上示例中，要為匿名內(nèi)容應(yīng)用樣式（不利用 list-style-image 的繼承特性），將會產(chǎn)生Class分類中的規(guī)則，當這條規(guī)則本應(yīng)該止于ID分類——所有分類中最確切的分類。

謹記: 所有元素都有同一種class，尤其是匿名內(nèi)容！

上面示例中的“差”規(guī)則強制每個菜單的圖標都要在包含書簽的菜單項內(nèi)進行測試。因為這里有很多菜單，這將是極其耗費的。相反，這條“好”規(guī)則將測試限制在書簽菜單（外圍容器，非單獨項）內(nèi)。

使用 -moz-image-region！

如果你正在開發(fā)針對Mozilla的代碼：將一系列圖像放置在一個單獨的文件中，然后使用 -moz-image-region 進行選擇，這比將他們分別放在自身的文件中來選擇要表現(xiàn)得更加良好。

使用局部樣式表

如果你能夠明確將樣式表作為XBL源，這些樣式僅僅應(yīng)用在被綁定的元素和其中的匿名內(nèi)容上。這會減小通用規(guī)則和子元素選擇器帶來的負面影響，因為他們考慮的元素會更少。

如非必要則避免特定瀏覽器的渲染特征

總有有一些針對特定瀏覽器的或者實驗性的標簽和CSS屬性，他們以前綴的形式來區(qū)分能夠起作用的瀏覽器，例如 -webkit、-moz、 -ms、-o 等等。一旦某個標簽或?qū)傩员粯藴驶@些前綴屬性就會被移除。舉個例子，在 border-radius 被標準化和被所有主流瀏覽器實現(xiàn)之前，你必須使用 -webkit-border-radius 和 -moz-border-radius 等屬性。

對特定渲染的前綴和標簽及屬性的標準化的變化保持意識，并且在任何可行的時間都要去避免使用任何特定渲染的特性。

最新評論