爲後代選擇器和ID選擇器而辯護

【本文譯自 Zeldman （作爲前端工程師，不要告訴我你不知道他是誰）在2012年11月寫的《[url=http://www.zeldman.com/2012/11/21/in-defense-of-descendant-selectors-and-id-elements/]IN DEFENSE OF DESCENDANT SELECTORS AND ID ELEMENTS[/url]》。】


除了偶爾更新下《Designing With Web Standards》，我這些年已經不再寫關於CSS和HTML的具體實踐和細節問題了。長江後浪推前浪——其他設計師和開發者接過了我的槍。在很大程度上，無論對他們還是對我們這個行業，這都是件好事。要說清楚代碼那些事，最佳人選永遠是那些每天花25小時沉浸其中的傢伙——我也曾是如此。當像我這樣的老傢伙轉向戰略和管理角色（讓我們有新的創新領域，也可以有新的寫作主題），新一代代碼高手也繼續着發現和傳播新知。這就是生命的神奇輪迴吧。

不過在這諸多美好之中，我偶爾也會發現狗屎。有一種觀念——如今甚至已固化成信條——即所謂[url=http://csswizardry.com/2012/11/code-smells-in-css/]應該避免使用id[/url]——因爲id“specificity【特化度】太高”——用class總是更可取。對這一信條，我必須稱之爲——胡扯。

據我所知，此觀念來自於Nicole Sullivan著名的[url=https://github.com/stubbornella/oocss/wiki]面向對象的CSS[/url]。這種書寫HTML和CSS的方法論被設計用於規模達數千頁面的網站——且這多達數千頁面的網站是由多達數十個前端工程師經過數年時間建造出來——且通常這建造過程缺乏統一準則或樣式指導方針（或者等到有統一準則和樣式指導方針之時已然太晚）。在這樣的網站上——在像Amazon或Facebook這樣從一開始就一鍋亂燉的網站上——因爲他們有一大幫廚子卻沒有一個主廚——在這樣的網站上，使用id和後代選擇器的組合確可能引發問題，特別是當笨拙的碼農試圖通過創建更specific【更特化】的後代選擇器規則來覆蓋基於id的後代選擇器規則的時候。

在這樣特定（而奇葩）的環境下，開發者們不斷決鬥般的把一條又一條css規則加入到巨大的一坨樣式表裏，這樣式表更像考古遺蹟，而非現代代碼的好範例。面對如此一坨，Nicole告誡避免基於id的後代選擇器或許是明智的。如果你倒了血黴要去弄一個龐大的、開發得一塌糊塗的網站，又不被允許按照常識和最佳實踐重構模板和CSS，你可能不得不依靠class而棄用後代選擇器和id。

但在幾乎所有其他環境下，正確運用id和後代選擇器更可取，因爲這樣更富語義，也更節約帶寬。

我一直以來所主張的使用id的方式，其實就是HTML5新增元素的前身。2000年時，我們沒有footer元素，爲了給該div中的內容賦以結構上的意義，我們這樣寫：div id="footer"。今天，根據人們訪問我們網站所用的瀏覽器和設備，我們可以選擇用HTML5的footer元素替代老方式。但若是我們不能使用HTML5元素，使用id也沒有什麼不對的。

至於後代選擇器，只要這個網站不是由100只猴子設計的，我們完全可以假設開發者能以協調的方式對具有id的div或者HTML5元素內的後代元素賦以樣式，並且處於不同id的div或HTML元素中的相同元素可以被賦以不同樣式。比如footer中的段落和列表項跟aside中的段落和列表項就可以被賦以不同樣式。id（或HTML5元素）和後代選擇器就是用來幹這個的。給sidebar中的每個段落元素都設上classname不僅無謂浪費帶寬，更是粗魯之極。

跟我念：id沒有任何問題，只要你正確運用（表達語義、表達結構、不濫用）。認爲class總是比後代選擇器和富有語義、表達結構的id更好，這種觀念全然謬誤。

請注意：我不是在貶低我的朋友Nicole Sullivan的面向對象的CSS對於那些一團亂麻的網站的作用，正如我不會貶低挖掘機對清理災難現場的作用。我只是不想用挖掘機來清理我的房間。


【完】