但是為什么到了CSS已經(jīng)如此強大(且瀏覽器支持度也都挺好)的年代，依然會出現(xiàn)那么多實質(zhì)還是以表現(xiàn)為中心提出的所謂“最佳實踐”？其實，這歸結(jié)起來，源于我們對于CSS復(fù)用的這種剛性需求。

以O(shè)OCSS為例，我們寫一組按鈕可能會這么寫：

.button-primary {
    width: 80px;
    height: 40px;
    background-color: green;
    ...
}

.button-error {
    width: 80px;
    height: 40px;
    background-color: red;
    ...
}

我不能每寫一個button都重復(fù)一遍寬高啊，要復(fù)用，所以我們可能會把公共部分提取出來

.button {
    width: 80px;
    height: 40px;
}

如果你秉承這個思路，當(dāng)哪天產(chǎn)品要求第一個按鈕要左排第二個要右排的時候，我估摸著你會很自然的這么去寫：

.float-left {
    float: left;
}
.float-right {
    float: right;
}

更甚者，哪天產(chǎn)品要求第二個按鈕跟右邊隔10像素，你會不會這么寫？

css我就不寫了mr10什么意思我猜你已經(jīng)知道了。。
且不說這種寫法中button本身就是一種冗余信息(我當(dāng)沒看見也罷)，mr10 則基本上無法忍受了，仔細想想這跟直接寫inline-style有什么差別？相反我寫inline-style更符合標(biāo)準(zhǔn)，至少我是掛載在專門用于描述表現(xiàn)的style屬性上面，而不是用來描述內(nèi)容的class上面。

基于這樣的一連串演進，最后大概會誕生出兩個癥狀：

樣式類 即一系列諸如 mr10 fl之類的class

多class癥 即幾乎每個元素上都要掛載至少一個class。

原因在于，如果我們需要達到復(fù)用的效果，最后必定會魔障出一條理念：樣式需具備獨立性與上下文無關(guān)，同時粒度需要夠小(樣式類／通用原子類)。

其中也有一個主要原因是我們對CSS的誤解

css ＝ 層疊樣式表，其關(guān)鍵詞在層疊

“復(fù)用”需求最后一定會導(dǎo)致我們樣式退化到平級的單class規(guī)則定義，因為這樣才能足夠無狀態(tài)。但實際上CSS最獨特的地方在于層疊，你避開這種機制從而來滿足復(fù)用需求，最后不單單喪失了CSS的能力，反而會催生出一系列不符合語義化標(biāo)準(zhǔn)的反模式。

但是我也說過，復(fù)用是剛需，而CSS又不具備抽象能力，所以我們只能眼睜睜的看著一坨坨屎流行么？

好在我們有預(yù)處理器

Sass/Less我這里就不一一贅述了，時至今日相比大家都很熟悉。為什么說最佳實踐是Sass/Less呢？簡單來說，就是這類預(yù)處理器在提供一定的抽象能力的同時，也不會破壞css自身的特性。拿上面的例子來看，如果我們使用Sass/Less的寫法：

%button {
    width:80px;
    height:40px;
}

.button-primary {
    @extend %button;
    background-color: white;
}

.button-success {
    @extend %button;
    background-color: green;
}
.button-error {
    @extend %button;
    background-color: red;
}

如果我們在項目級別需要統(tǒng)一的配色，可以做進一步的抽象

$primary-bgc: white;
$success-bgc: green;
$error-bgc: red;
.button-primary {
    @extend %button;
    background-color: $primary-bgc;
}
.button-success {
    @extend %button;
    background-color: $success-bgc;
}
.button-error {
    @extend %button;
    background-color: $error-bgc;
}

同樣的手段還有mixin。
我們可以將我們需要復(fù)用的“樣式類”抽象成placeholder／mixin(對于“通用原子類”這樣的需求我推薦用placeholder)，然后使用語義化的 class／屬性 作為鉤子，來組裝這些“原子類”(但實際上這些“原子類”對CSS而言是不可見的)。比如我們用a標(biāo)簽來模擬一個提交按鈕，我們應(yīng)該這樣寫：

提交

a[role="submit-button"] {
    @include .button-success;
}

所以css的最佳實踐應(yīng)該是： Sass + OOCSS/BEM/METACSS

這里有一個關(guān)鍵點在于，我們在使用這些css抽象方法論來寫sass的時候，切記不要把中間變量暴露給css。什么意思呢，button那個例子我這樣來寫

.button{
    width: 80px;
    height: 40px;
}
.button-primary {
    @extend .button;
}

此時button對于css而言是可見的。對于button這類抽象產(chǎn)物，我們應(yīng)該用placeholder和mixin代替，確保其對css的不可見從而保證web的“純度”。(這也是我不推薦Less的原因，Less最大的失誤在于沒有placeholder的設(shè)計)

到這里估計思考過的同學(xué)會有疑問：很多場景可能并沒那么容易語義化，比如我要第一個元素左浮動，第二個元素右浮動，第三個又左浮動，第四個右浮動。。。

這里需要提到另一個經(jīng)常被誤解的點：selector。selector作為HTML與CSS的結(jié)合點，實質(zhì)上也是需要語義化的。tag跟id是天生帶語義的，主要問題還是出在class上。我們總是嘗試在class上掛載一些表現(xiàn)型的“名稱”。這里面有一小部分確實是由于CSS本身的不完美(比如layout這種場景細則就比較難語義)導(dǎo)致的，但是過多的則歸咎于我們語義化動力不足及對selector的認知不夠。語義化動力不足完全是主觀因素這里不贅述，對selector認知不夠則是最普遍存在的情況。推薦閱讀：為后代選擇器及id選擇器辯護 結(jié)合智能選擇器的語義化的CSS

綜上所述，如果要秉持純粹的Web開發(fā)，最佳實踐是：
合適的語義化標(biāo)簽 ＋ 語義化selector ＋ Sass

其實我不太想回答這種問題。。。我更想反問：為什么不按標(biāo)準(zhǔn)來？??！

一定要說的話：

推行標(biāo)準(zhǔn)的目的是為技術(shù)交流構(gòu)建一個統(tǒng)一的上下文語境平臺，提高溝通效率，避免雞同鴨講。

同時標(biāo)準(zhǔn)跟規(guī)范的制定是經(jīng)過一群 資深開發(fā)者／科學(xué)家 經(jīng)過仔細研究及社區(qū)討論的，一套完整的一致的基礎(chǔ)架構(gòu)系統(tǒng)是推進生態(tài)發(fā)展的必要條件。

就Web語義化這件事情而言，如果你的HTML是基于標(biāo)準(zhǔn)來編寫的，意味著你的頁面具備更多的可能性。比如搜索引擎友好，多終端適配(不是響應(yīng)式。。是指兼容各種閱讀設(shè)備、讀屏軟件等。參見microformats)，更智能的風(fēng)格查錯能力。

在前端開發(fā)體系里，能體系專業(yè)性的地方不多。。拿程序復(fù)雜度而言，它跟大型后端系統(tǒng)差不止一個量級(前端的難度在于工程上)。。好不容易有一個能體現(xiàn)專業(yè)素養(yǎng)的領(lǐng)域(語義化Web)，為什么我們不抓住機會為自己正名呢。。

推薦閱讀：

http://hax.iteye.com/blog/497338

http://hax.iteye.com/blog/500015

http://hax.iteye.com/blog/849826