編寫高效的CSS

好了，所以在另一些問題正在討論，並提及此鏈接：編寫高效的CSS

https://developer.mozilla.org/en/Writing_Efficient_CSS

在那篇文章中，他們說，有些事情我不知道，但在此之前我問他們，我應該問這個......是否適用於由Firefox解釋的CSS？原諒我的noobness，但我不確定他們意味着什麼Mozilla UI。（不要傷害我！）

如果它不適用，當他們說：

避免後代選擇！

後代選擇器是CSS中最昂貴的選擇器。這是非常昂貴，特別是如果使用選擇器的規則在標籤或通用類別中。經常需要什麼是孩子選擇器。在UI CSS中禁止使用選擇器，明確批准了您的皮膚模塊所有者。
* BAD - treehead treerow treecell { } 
* BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { } 

的後代選擇僅僅是一個空間？那麼孩子和後代之間會有什麼不同呢？孩子是另一個元素，但不是像後代一樣？在我寫作時，我想我可能已經弄明白了。後裔可能是小孩/孫子/曾孫/等等？孩子只有一個深？

對不起，我的問題愚蠢的水平......只是想知道，因爲我一直在我的網站CSS不斷使用後代。但是，是的，如果這不是關於Firefox，那麼這整個問題是沒有意義的...

如果不是關於Firefox，有沒有人有鏈接到一個文章解釋效率的Firefox或瀏覽器一般？

來源

2009-08-14 Ian Storm Taylor

是的。而且，兒童選擇器在IE6中不起作用，所以如果這種支持是必須的，那麼你幾乎是骨子裏的。 – jason 2009-08-14 18:03:40

首先 - 本文中的建議是不是HTML頁 - 他們是專門爲Mozilla的UI - XUL，所以它可能是XUL最佳實踐，而不是HTML。

在平均HTML頁面上應用CSS是加載頁面時發生的最快的事情之一。
另外，文章可能會建議應用css規則的最快方式，但是花費多少？例如，他們建議沒有按規則不止一個類：

BAD - .treecell.indented {}
GOOD - .treecell縮進{}

這幾乎離譜。它可能會導致更快的CSS，但誰在乎？假設你已經有.treecell和.indented，以下這些建議會導致複雜的邏輯，更難維護，複製CSS規則較硬的JavaScript（花費了很多更多的CSS）等
他們建議不使用全CSS選擇器的豐富性和用平面類替換這些選擇器，這是一種恥辱。

來源

2009-08-14 18:33:54 Kobi

實際上，文章給出了「treecell.indented」而不是「.treecell.idented」作爲「BAD」。它給出了一個類似「p.indented」的通用示例，並且要點是「不要限定具有標記名稱的類分類規則」。它沒有說每個規則有多個類別。 – 2009-11-13 04:44:57

@pw - 你是對的。我無法解釋這是怎麼發生的，但文章中有足夠的例子說明人們每天在CSS上做什麼，這在XUL上是不推薦的。經你的允許，我會留下答案。 :) – Kobi 2009-11-13 10:10:16

後裔可能是孩子/孫子/曾孫/等？孩子只有一個深？

是的，正好。由於孩子只能是一個深度，因此渲染引擎必須通過遞歸搜索來檢查規則是否匹配。

是的，該文章是關於Firefox和瀏覽器一般。大多數（所有？）的內容適用於任何頁面渲染引擎。

來源

2009-08-14 18:01:55 Amber

「父母>孩子」只是一步下降，而「祖先後裔」可能是一個或多個步驟。

更好的方法是儘可能使用「#id」標籤，以便減少DOM搜索。

來源

2009-08-14 18:02:33

的UI CSS是一種樣式瀏覽器的內部 - 設置對話框，擴展接口等

後裔和兒童是不同的，孩子們更具體的，並導致更不必考慮。

來源

2009-08-14 18:02:47

...在我寫作時，我想我可能已經弄明白了。後裔可能是小孩/孫子/曾孫/等等？孩子只有一個深？

確實。

有一件事我可以對事物的效率方面補充說明的是：不要使用*，除非你是說真的。規則非常密集，大多數人只能指定他們真正想要的元素。

來源

2009-08-14 18:09:03 Oli

我確實在添加重置時學到了這一點。但是，謝謝重申！我甚至沒有意識到那篇文章中描述的一些普遍性是可能的，但也許那是更好的嘿嘿。 – 2009-08-14 18:14:05

@Oli：我知道這是一個直接的引用，但褻瀆標記了，所以我編輯了它。可笑，我知道，但我認爲這不會對你的答案帶來任何影響。 – 2009-08-14 19:56:58

與孩子選擇的問題是，它沒有得到很好的支持。當然，這可能已經修復在較新的IE瀏覽器上。

在任何情況下，對網頁編寫CSS時，它不會是大問題。我懷疑你在頁面加載中保存的秒數會被注意到。這篇文章似乎更傾向於人們爲真正的瀏覽器寫東西，而不是網站。

來源

2009-08-14 18:18:12 Karl

O'Reillys「Even Faster Web Sites"對這個題目一整章‘簡化CSS選擇’，它引用您在Mozilla的鏈接。

我覺得有兩點是值得銘記。

是的，如果你儘可能地做到了這一點，那麼你的HTML和CSS將會是一堆亂七八糟的樣式，並且由於文件大小的增加可能會變得更加低效。開發人員應該選擇最佳平衡點。每寫一行，讓它工作，然後看看有什麼好處。
正如另一位評論者指出的那樣，瀏覽器需要幾毫秒才能確定如何在頁面加載時應用您的樣式。但是，這可以對DHTML產生更大的影響。每次更改DOM時，瀏覽器都會將整個樣式表重新應用於頁面。在這種情況下，許多效率低下的選擇器可能會對您的頁面產生明顯的影響（感覺到的滯後/無反應）。

來源

2009-08-14 20:53:00

Google的Page Speed（Firefox/Firebug附加組件）文檔包含good page on efficient CSS。

來源

2009-11-13 05:02:12

編寫高效的CSS

回答

相關問題