在定義了規(guī)范后，元素、屬性（attribute）及屬性（attribute）值的語義還要受到開發(fā)商共同選擇和實(shí)現(xiàn)的影響，這就導(dǎo)致了后期規(guī)范化的約定好的語義要進(jìn)行修改（這是HTML設(shè)計(jì)的一個(gè)原則）。

關(guān)于語義

語義是研究符號(hào)和標(biāo)志，以及他們所代表的事物之間的關(guān)系的。在語言學(xué)里，主要是研究符號(hào)所表達(dá)的意思（如單詞、短語或聲音）。Web前端開發(fā)中，語義主要涉及到了約定好的HTML元素、屬性（attribute）及屬性（attribute）值的意義（包括一些擴(kuò)展，如微數(shù)據(jù)）。這些約定好的語義，通常是正式的規(guī)范，可以用來更好的理解一個(gè)網(wǎng)站的各方面信息。但是，在定義了規(guī)范后，元素、屬性（attribute）及屬性（attribute）值的語義還要受到開發(fā)商共同選擇和實(shí)現(xiàn)的影響，這就導(dǎo)致了后期規(guī)范化的約定好的語義要進(jìn)行修改（這是HTML設(shè)計(jì)的一個(gè)原則）。

區(qū)分不同類型的HTML語義

編寫“具有語義的HTML”原則是現(xiàn)代、專業(yè)前端開發(fā)的一個(gè)基礎(chǔ)。大多數(shù)的語義和自然存在的或預(yù)期內(nèi)容的多方面相關(guān)（例如，h1元素、lang屬性(attribute)、type屬性(attribute)的email值、微數(shù)據(jù)）。

然而，并非所有的語義需要根據(jù)內(nèi)容衍生出來的。類名不能是“非語義”的。無論使用什么名字，他們都需要有意義、有目的。類名語義跟HTML語義不同。我們可以使用HTML元素，某些HTML屬性（attributes）、微數(shù)據(jù)等約定的“global”語義，他們的目的不會(huì)和那些網(wǎng)站、特定的應(yīng)用程序的“l(fā)ocal”語義產(chǎn)生混淆。那些“l(fā)ocal”的語義是包含在屬性（attribute）值里的，如class屬性（attribute）。

盡管HTML5 specification section on classes再次假定“最佳實(shí)踐”是：

“鼓勵(lì)作者使用[類屬性（attribute）]值來描述實(shí)際內(nèi)容的本質(zhì)，而不是描述那些所需的內(nèi)容。”

本身沒有理由這樣做的。實(shí)際上，在開發(fā)大型網(wǎng)站或應(yīng)用程序時(shí)，這樣經(jīng)常會(huì)是一個(gè)阻礙。

內(nèi)容層語義本來服務(wù)于HTML元素和其他屬性(attribute)。

類名給機(jī)器或者訪問者提供很少或沒有用的語義信息，除非是商定好的名字（并且是機(jī)器可讀的）的一小部分——微格式。

使用類名主要的目的是為了使用CSS和javascript。如果你不需要在你的web文檔里添加表現(xiàn)和行為，那么在你的HTML里，就可能不需要類名。

類名應(yīng)該傳達(dá)有用的信息給開發(fā)者。當(dāng)你在閱讀一個(gè)DOM代碼段的時(shí)候，它有助于理解一個(gè)特定的類名是做什么的，特別是在多個(gè)開發(fā)者的團(tuán)隊(duì)里，前端工作者并不是唯一開發(fā)HTML組件的。

看一個(gè)非常小的例子：

<div class="news">

  <h2>News</h2>

  [news content]

</div>

這里的類名“news”不會(huì)告訴你任何信息，從內(nèi)容上看，它本身就不是很明顯。關(guān)于這個(gè)組件的總體結(jié)構(gòu)沒有給你提供信息，它不能夠用于非“news”的內(nèi)容。試著將你的類名語義和實(shí)際的內(nèi)容緊密結(jié)合，會(huì)降低架構(gòu)可擴(kuò)展性的能力和被其他開發(fā)者使用的易用性。

內(nèi)容獨(dú)立的類名

在一個(gè)設(shè)計(jì)里，另一種方法是根據(jù)重復(fù)結(jié)構(gòu)和功能模式衍生類名語義。復(fù)用性最高的組件是那些內(nèi)容獨(dú)立的類名。

我們不應(yīng)該擔(dān)心層與層之間的連接是否清晰明確，應(yīng)該擔(dān)心那些反映具體內(nèi)容的類名。這樣做并不是意味著類名“無語義”，它僅僅意味著這些類名的語義不是根據(jù)內(nèi)容衍生出來的。如果一些額外的HTML元素有助于創(chuàng)造更強(qiáng)大的、靈活的、可重用的組件，我們就不介意使用額外的HTML元素，這只是意味著你使用了更多的元素來標(biāo)記內(nèi)容。

前端架構(gòu)

一個(gè)組件、模版、面向?qū)ο蟮募軜?gòu)的目的是能夠開發(fā)一些可重用的組件，這些組件包含了一系列不同的內(nèi)容類型。類名語義在大型應(yīng)用程序里的重要性在于它是由實(shí)用性衍生出來并且很好的服務(wù)于這個(gè)組件的主要目的-為開發(fā)人員提供有意義，靈活，可復(fù)用的表現(xiàn)或行為性的接口，以便使用。

可復(fù)用、可組合的組件

總的來說，可擴(kuò)展的HTML或CSS必須依賴HTML里的類來創(chuàng)建可復(fù)用的組件。一個(gè)靈活的、可復(fù)用的組件既不是依賴于存在的DOM樹里的某個(gè)部分，也不需要使用特定的元素類型。它應(yīng)該能夠適應(yīng)不同的容器，并且可以容易的加上樣式。如果有必要，添加額外的HTML元素（除了那些僅用來標(biāo)記內(nèi)容的HTML元素）可以用來創(chuàng)建更強(qiáng)健的組件。一個(gè)很好的例子就是Nicole Sullivan所說的的media object.

易于組合的組件得益于使用選擇器類型，而避免使用類型選擇器。下面的例子降低了btn部分和uilist部分易組合性。問題在于.btn的優(yōu)先級(jí)比.uilist a（會(huì)覆蓋重復(fù)的屬性樣式）的優(yōu)先級(jí)低，并且uilist需要a作為子結(jié)點(diǎn)。

.btn { /* styles */ }

.uilist { /* styles */ }

.uilist a { /* styles */ }

<nav class="uilist">

  <a href="#">Home</a>

  <a href="#">About</a>

  <a class="btn" href="#">Login</a>

</nav>

提高一個(gè)組件部分和uilist部分的易組合性的一個(gè)方法是使用類給子DOM元素添加樣式。這樣可以減少樣式規(guī)則的特性，但是最大的好處就是允許你將結(jié)構(gòu)上的樣式應(yīng)用到任何類型的子節(jié)點(diǎn)上。

.btn { /* styles */ }

.uilist { /* styles */ }

.uilist-item { /* styles */ }

<nav class="uilist">

  <a class="uilist-item" href="#">Home</a>

  <a class="uilist-item" href="#">About</a>

  <span class="uilist-item">

    <a class="btn" href="#">Login</a>

  </span>

</nav>

Javascript特定類

使用javascript特定類有助于降低因組件主題樣式或結(jié)構(gòu)改變而導(dǎo)致原來應(yīng)用在上面的javascript不起作用的風(fēng)險(xiǎn)。我發(fā)現(xiàn)一個(gè)方法是使用某些只給javascript使用的類——js-*——不給這些特殊類添加任何樣式呈現(xiàn)。

<a href="/login" class="btn btn-primary js-login"></a>

改變組件的結(jié)構(gòu)或主題將無意中影響任何所需的JavaScript行為和復(fù)雜的功能，使用這種方法，你可以減少這種無意中的情況發(fā)生。

組件修飾符

組件經(jīng)常會(huì)有些變化，和基組件的呈現(xiàn)有稍微的不同，如不同顏色背景或者邊框。有兩種模式可以使用來達(dá)到這些變化。我把這兩種模式稱為“單類”模式和“多類”模式。

“單類”模式

.btn, .btn-primary { /* button template styles */ }

.btn-primary { /* styles specific to save button */ }

<button class="btn">Default</button>

<button class="btn-primary">Login</button>

“多類”模式

.btn { /* button template styles */ }

.btn-primary { /* styles specific to primary button */ }

<button class="btn">Default</button>

<button class="btn btn-primary">Login</button>

在使用“單類”模式時(shí)，如果你使用了預(yù)處理器，你可能使用Sass的@extend功能減少一些維護(hù)的工作。然而，即使有預(yù)處理器的幫助，我優(yōu)先選擇的是使用“多類”模式，在HTML里添加類修飾符。

我發(fā)現(xiàn)“多類”模式是一個(gè)更具有擴(kuò)展性的模式。例如，使用基于btn的組件，進(jìn)一步添加了5種按鈕類型和3種按鈕尺寸。使用“多類”模式，最終你需要9個(gè)類，通過混合匹配達(dá)到效果。但是使用“單類”模式你需要24個(gè)類。

如果需要，使用組件修飾符也比較容易根據(jù)上下文調(diào)整一個(gè)組件。比如你可能在另一個(gè)組件里對(duì)btn的外觀要做些細(xì)微的調(diào)整，可以這么做：

/* "multi-class" adjustment */

.thing .btn { /* adjustments */ }

/* "single-class" adjustment */

.thing .btn,

.thing .btn-primary,

.thing .btn-danger,

.thing .btn-etc { /* adjustments */ }

“多類”模式意味著你只需要一個(gè)單獨(dú)的內(nèi)部組件選擇器去匹配任意類型的btn——在這個(gè)組件里被應(yīng)用了btn的樣式元素?！皢晤悺蹦Ｊ揭馕吨阈枰獙懗鋈魏慰赡艿陌粹o類型，并且在任何時(shí)候改變了一個(gè)按鈕的外觀，你都需要調(diào)整這個(gè)選擇器。

結(jié)構(gòu)化類名

當(dāng)創(chuàng)建組件時(shí)——并添加了“主題“——一些類用于區(qū)分不同的組件，一些類用于組件修飾符，一些類和DOM結(jié)點(diǎn)關(guān)聯(lián)，他們被包含在一個(gè)較大的抽象呈現(xiàn)組件里。

很難判斷btn（組件）、btn-primary(修飾符)、btn-group(組件)和btn-group-item（組件子對(duì)象）之間的關(guān)系，因?yàn)檫@些名字不能清楚的使人明白這些類的用途。沒有一致的模式。

在過去的一年里我一直在嘗試命名模式，這種模式能夠幫助我更快的理解DOM片段里結(jié)點(diǎn)間的關(guān)系，而不是試著來回的在HTML、CSS和JS文件之間查看， 拼湊出網(wǎng)站的架構(gòu)。這種模式主要受BEM系統(tǒng)方法命名的影響，但是，被我改編成一種更容易閱讀的形式。

t-template-name t-template-name--modifier-name t-template-name__sub-object t-template-name__sub-object--modifier-name  component-name component-name--modifier-name component-name__sub-object component-name__sub-object--modifier-name  is-state-type  js-action-name js-component-type

我把一些結(jié)構(gòu)當(dāng)做抽象的“模板”，其它則當(dāng)作更清晰的組件（通常建立在“模板”上）。但是這種區(qū)分并非總是必要的。

這只不過是我目前發(fā)現(xiàn)的一個(gè)命名模式而已。它可以采取任何形式。但是這種模式的好處在于它消除了那些只依賴（單）連接符，或者下劃線，或者是駝峰格式的模糊的類名。

原始文件大小和HTTP壓縮

任何關(guān)于模塊化與可擴(kuò)展的CSS的討論關(guān)心的是文件大小和“膨脹“。Nicole Sullivan的言論中經(jīng)常會(huì)提到文件大小存儲(chǔ)（以及維護(hù)改進(jìn)），并提到了像Facebook這樣的公司采用這種方法的經(jīng)歷。進(jìn)一步的，我想我會(huì)分享我在預(yù)處理輸出時(shí)的HTTP壓縮效果，以及大量使用HTML類的一些事情。

當(dāng)Twitter 的Bootstrap剛面世時(shí)，我重寫了編譯好的CSS，以便更好地與手動(dòng)操作的文件比較大小。在最小化兩個(gè)文件之后，手動(dòng)操作的CSS文件比預(yù)處理程序輸出的小10%。但是當(dāng)兩個(gè)文件都通過gzip壓縮后，預(yù)處理程序輸出的CSS文件比手動(dòng)操作的小了5%。

這強(qiáng)調(diào)了比較HTTP壓縮后文件大小的重要性，因?yàn)闇p小文件大小并不能說明一切。它暗示了有經(jīng)驗(yàn)的CSS開發(fā)者在用預(yù)處理程序時(shí)不必太過關(guān)心編譯后的CSS中有一定程度的重復(fù)，因?yàn)榻?jīng)過HTTP壓縮后，文件將變得更小。通過預(yù)處理程序處理更易于維護(hù)的CSS代碼所帶來的好處，要?jiǎng)龠^關(guān)注原始CSS和壓縮后輸出的CSS的美觀或文件大小。

在另一個(gè)實(shí)驗(yàn)中，我從網(wǎng)站上弄了一個(gè)60KB的HTML文件（由很多可重用的組件組成），刪除了它的每一個(gè)class屬性（attribute）。這樣處理之后，文件減小到25KB。當(dāng)原始文件與修改過的文件都通過gzip壓縮后，它們的大小分別變?yōu)?.6KB和6KB——只相差1.6KB。自由使用class所導(dǎo)致的實(shí)際文件大小的結(jié)果已經(jīng)不值得再去強(qiáng)調(diào)了。

我如何學(xué)會(huì)停止擔(dān)憂的…

多年來，許多技術(shù)熟練的開發(fā)人員的經(jīng)驗(yàn)，已經(jīng)改變了大型網(wǎng)站和應(yīng)用程序的開發(fā)方式。盡管如此，對(duì)于個(gè)人來說，放棄“語義化的HTML”的觀念，意味著將由內(nèi)容來決定類名（即使非要這么做，也只能作為最后的手段來使用），這通常需要你開發(fā)完一個(gè)大型的應(yīng)用程序后，才能夠強(qiáng)烈地意識(shí)到這種做法不靠譜的一面。你必須準(zhǔn)備好拋棄老觀念，尋找替代方案，甚至重新審視以前已被你摒棄的方法。

一旦你開始寫大型的網(wǎng)站和應(yīng)用，你和其他人不僅必須去維護(hù)它，而且還得積極地迭代改進(jìn)。你很快會(huì)意識(shí)到即使你盡了最大的努力，你的代碼仍然開始變得越來越難以維護(hù)。已經(jīng)有一些人提出了他們自己的方法來解決這些問題：Nicole的博客和面向?qū)ο蟮腃SS項(xiàng)目，Jonathan Snook的可擴(kuò)展的模塊化結(jié)構(gòu)CSS，以及Yandex開發(fā)的BEM方法。這些方法值得我們花時(shí)間去探索。

當(dāng)你選擇了以減少編寫和編輯CSS的時(shí)間為目的的方式來編寫HTML和CSS時(shí)，那么如果你想改變它們的樣式，你就必須接受花更多的時(shí)間去改變HTML元素的class。無論是前端還是后端開發(fā)者 —— 任何人都可以重新排列預(yù)建的“樂高積木”，這將是相當(dāng)實(shí)用的；事實(shí)證明，沒有人會(huì)CSS魔法。