關(guān)于語義
語義研究的是標志與符號之間的關(guān)系，以及它們所代表的意義。在語言學(xué)中，它主要是研究這些標志（如單詞，短語，或者聲音）在語言中的意義。而在前端開發(fā)領(lǐng)域，語義主要涉及的是HTML元素、屬性和屬性值（包括像Microdata這樣的擴展）所約定的意義。這些在規(guī)范中常用的正式約定語義，可以幫助程序（以及后來參與開發(fā)的人）更好地理解一個網(wǎng)站各方面的信息。然而，即使這些元素、屬性和屬性值的語義是正式化的，它們依然得服從于開發(fā)者的適應(yīng)程度以及共同選擇的結(jié)果。這使得正式的約定語義也可能會在今后被修改（而這正是HTML設(shè)計原則之一）。
區(qū)分不同類型的HTML語義
遵守編寫“語義化的HTML”這個原則，是現(xiàn)代專業(yè)前端開發(fā)的基礎(chǔ)之一。絕大多數(shù)的語義都與當前或預(yù)期的內(nèi)容性質(zhì)有關(guān)（如：h1元素，lang屬性，type屬性的email值，Microdata）。
然而，并非所有的語義都需要以內(nèi)容為導(dǎo)向。類名不能“無語義”。不管是用什么名字命名，它們都必須要有意義與目的。類名的語義可以和那些HTML元素不同。我們可以借助HTML元素、某些HTML屬性、Microdata等所具有的“全局性”語義，然后利用網(wǎng)站或應(yīng)用的“局部性”特定語義加以區(qū)分，這些特定語義通常包含在屬性值中，比如class屬性。
盡管在HTML5規(guī)范的class屬性這一章節(jié)中重申了這個假定的“最佳實踐”…
…鼓勵開發(fā)者使用class屬性值描述實際內(nèi)容，而不是描述期望展現(xiàn)的內(nèi)容。
…并沒有什么內(nèi)在的原因非這樣做不可。事實上，當這種方法在大型網(wǎng)站或者應(yīng)用中運用時，它往往會成為一種障礙。
HTML元素和其它屬性已經(jīng)提供了內(nèi)容層的語義
對于機器或訪問者來說，類名所能透露的有用的語義信息非常少，甚至沒有。除非它是已經(jīng)約定的那一小部分名稱（機器同樣可讀） —— Mircoformats
類名的主要用途是成為CSS和JavaScript的鉤子。如果你不需要為你的頁面添加表現(xiàn)和行為，那么你或許不必在你的HTML里添加類名
類名應(yīng)該為開發(fā)者傳達有用的信息。當你閱讀一個DOM片段時，它將有助于理解某個類名的具體作用。尤其是在多人協(xié)作的開發(fā)團隊里，與HTML組件打交道的可不光只有前端開發(fā)者。
舉一個非常簡單的例子：
XML/HTML Code
1.<div class="news">
2. <h2>News</h2>
3. [news content]
4.</div>
當內(nèi)容還不明顯的時候，這個類名news不能告訴你任何事情。它沒有向你提供關(guān)于這個組件整體結(jié)構(gòu)的信息，而且一旦內(nèi)容不再是“新聞”時，使用這個類名就顯得非常不妥。類名的語義過分貼近內(nèi)容，架構(gòu)既不容易擴展，也不容易為其他開發(fā)人員所用。
與內(nèi)容無關(guān)的類名
從某個設(shè)計模式的結(jié)構(gòu)與功能中提取類名的語義是一種更好的方法。那些類名與內(nèi)容無關(guān)的組件可重用性更高。
我們不應(yīng)該害怕讓各層之間的關(guān)系變得清晰而明確（這里應(yīng)該是指結(jié)構(gòu)層、內(nèi)容層等，譯者注），而不是用類名嚴格地反應(yīng)明確的內(nèi)容。這樣做不會使類名“無語義”，這只是表明它們的語義并不取決于內(nèi)容。我們也不應(yīng)該害怕使用額外的HTML元素，只要它們能幫助你創(chuàng)建更強壯、更靈活且更具重用性的組件。這樣做不會使HTML變得“無語義”，這僅僅意味著你標記內(nèi)容所使用的元素數(shù)量超過了最小值而已。
前端架構(gòu)
組件、模板、面向?qū)ο蟮捏w系結(jié)構(gòu)的目的是能夠開發(fā)出一種數(shù)量有限的可重復(fù)使用的組件，它可以在一定范圍內(nèi)包含不同的內(nèi)容類型。在大型的應(yīng)用程序中，對類名語義來說最重要的事情是，能夠用實用主義服務(wù)于它們的主要目的 —— 提供有意義的、靈活的、可重復(fù)使用的表現(xiàn)或行為的鉤子供開發(fā)者使用。
可重用且可組合的組件
總的來說，可擴展的HTML/CSS必須依賴HTML中的class，以便創(chuàng)建可重用的組件。一個靈活的、可重用的組件，既不依賴DOM樹中的某一部分，也不需要使用特定類型的元素。它應(yīng)該能適應(yīng)不同的容器，并且可以很容易地更換主題。如果有必要，額外的HTML元素（超出標記內(nèi)容所必須的元素之外的元素）可以讓組件更加強壯。Nicole Sullivan所說的media object就是一個很好的例子。
避免用類型選擇器支持class，可以讓組件更容易合并。下面這個例子中，btn組件與uilist組件不易于合并。問題在于.btn的權(quán)重比.uilist a要小（這將覆蓋任何共享屬性）。而且ulist組件需要錨點作為子節(jié)點。
XML/HTML Code
1..btn { /* styles */ }
2..uilist { /* styles */ }
3..uilist a { /* styles */ }
4.
5.<nav class="uilist">
6. <a href="#">Home</a>
7. <a href="#">About</a>
8. <a class="btn" href="#">Login</a>
9.</nav>
一種讓uilist組件與其它組件輕松組合的方法是，uilist的子級DOM元素用class來添加樣式。盡管這會降低權(quán)重，但是它的主要好處在于，它為你提供了處理子節(jié)點的任何結(jié)構(gòu)樣式的選擇權(quán)。
XML/HTML Code
1..btn { /* styles */ }
2..uilist { /* styles */ }
3..uilist-item { /* styles */ }
4.
5.<nav class="uilist">
6. <a class="uilist-item" href="#">Home</a>
7. <a class="uilist-item" href="#">About</a>
8. <span class="uilist-item">
9. <a class="btn" href="#">Login</a>
10. </span>
11.</nav>
JavaScript專用類
使用某種形式的JavaScript專用類，可以降低因組件樣式或結(jié)構(gòu)的改變導(dǎo)致JavaScript失效的風(fēng)險。我已經(jīng)找到了一種非常有效的方法，那就是專為JavaScript的鉤子使用一種特定的類——js-*——不要在這個類名上添加任何描述。
XML/HTML Code1.<a href="/login" class="btn btn-primary js-login"></a>
在你修改組件的結(jié)構(gòu)或樣式的時候，可能會不經(jīng)意間對那些必要的JavaScript行為和復(fù)雜的功能造成影響，用這種方法的話，可以降低這種可能性。
組件修改器
組件常常會有一些變體，它們與基本組件只有細微的差別。比如，不同的背景色或者邊框。主要有兩種創(chuàng)建這些組件變體的模式。我將它們稱為“單類名”模式和“多類名”模式。
單類名模式
XML/HTML Code
1..btn, .btn-primary { /* 按鈕模板樣式 */ }
2..btn-primary { /* 主按鈕的特殊樣式 */ }
3.
4.<button class="btn">Default</button>
5.<button class="btn-primary">Login</button>
多類名模式
XML/HTML Code
1..btn { /* 按鈕模板樣式 */ }
2..btn-primary { /* 主按鈕的特殊樣式 */ }
3.
4.<button class="btn">Default</button>
5.<button class="btn btn-primary">Login</button>
如果你使用預(yù)處理程序，你可以用Sass的@extend功能，以減少一些在使用“單類名”模式時所涉及的維護工作。然而，即使有預(yù)處理程序的幫忙，我依然傾向于使用“多類名”模式，并在HTML中修改類名。
我發(fā)現(xiàn)這是一種更具擴展性的模式。比如，要實現(xiàn)一個基本的btn組件，并增加5種類型的按鈕與3種額外的尺寸。用“多類名”模式的話只要9個class就可以搞定，用“單類名”模式則需要24個class。
如果需要的話，它也更容易讓上下文環(huán)境適應(yīng)組件。你可能想對出現(xiàn)在其它組件中的任一btn做一些細節(jié)調(diào)整。
XML/HTML Code1./* “多類名”樣式調(diào)整 */
2..thing .btn { /* 相應(yīng)的樣式調(diào)整 */ }
3.
4./* “單類名”樣式調(diào)整 */
5..thing .btn,
6..thing .btn-primary,
7..thing .btn-danger,
8..thing .btn-etc { /* 相應(yīng)的樣式調(diào)整 */ }
“多類名”模式意味著，你只需要用一個單獨的組件內(nèi)部選擇器，便可以改變所有類型的btn元素的樣式?！皢晤惷蹦Ｊ揭馕吨?，你必須顧及所有可能的按鈕類型，并在創(chuàng)造一個新的按鈕變體時調(diào)整這個選擇器。
結(jié)構(gòu)化的類名
當創(chuàng)建一個組件時——并為之添加了“主題”——其中一些class被用來區(qū)分各個組件，一些class被當做組件的修改器，其它的class則被用來關(guān)聯(lián)DOM節(jié)點，它們一起被包含在一個較大的抽象組件中。
很難去判斷btn（組件）、btn-primary（修改器）、brn-group（組件）和btn-group-item（組件子對象）之間的關(guān)系，這是因為這些名字不能清晰地表現(xiàn)class的目的。沒有一致的模式。
在過去的一年中，我一直在嘗試命名模式，目的是能幫助我快速理解在一個DOM片段中節(jié)點的表象之間的關(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</p> <p>component-name
component-name--modifier-name
component-name__sub-object
component-name__sub-object--modifier-name</p> <p>is-state-type</p> <p>js-action-name
js-component-type
我將一些結(jié)構(gòu)當做抽象的“模板”來處理，其它的則視為更清晰的組件（通常建立在“模板”上）。但是這種區(qū)分并非總是必要的。
這僅僅是我目前發(fā)現(xiàn)的一種有用的命名模式。命名模式可以采用任何形式。但這種命名模式的好處在于消除了模糊的類名，只依賴（單）連接符，或者下劃線，或者是駝峰格式。
原始文件大小和HTTP壓縮的注意事項
任何關(guān)于模塊化與可擴展的CSS的討論都會談及對文件大小與“膨脹”的擔(dān)心。Nicole Sullivan的言論中經(jīng)常會提到文件大小的存儲（以及維護改進），并提到了像Facebook這樣的公司采用這種方法的經(jīng)歷。進一步的，我想我會分享我在預(yù)處理輸出時的HTTP壓縮效果，以及大量使用HTML類的一些事情。
當Twitter Bootstrap剛剛問世的時候，我重寫了已編譯的CSS，以便更好地與手動操作的文件比較大小。在最小化所有的文件之后，手動操作的CSS文件比預(yù)處理程序輸出的小10%。但是當所有的文件都通過gzip壓縮后，預(yù)處理程序輸出的CSS文件比手動操作的小了5%。
這強調(diào)了比較HTTP壓縮后文件大小的重要性，因為減少的文件大小并不能說明全部問題。它暗示了有經(jīng)驗的CSS開發(fā)者在用預(yù)處理程序時不必太過關(guān)注編譯后的CSS中一定程度的重復(fù)，因為它將在HTTP壓縮后變得更小。通過預(yù)處理程序處理更易于維護的CSS代碼所帶來的好處，要勝過關(guān)注原始CSS和壓縮后輸出的CSS的美觀或文件大小。
在另一個實驗中，我從線上扒了一個60KB的HTML文件（由很多可重用的組件組成），并刪除了它的每一個class屬性。這樣處理之后，文件大小減小到25KB。當原始文件與扒下來的文件都通過gzip壓縮后，它們的大小分別變?yōu)?.6KB和6KB——只相差1.6KB。自由使用class所導(dǎo)致的實際文件大小的結(jié)果已經(jīng)不值得再去強調(diào)了。
公眾號
事業(yè)單位
當前位置：
公考類
招聘類
各類考試