關於語意
語意研究的是標誌與符號之間的關係，以及它們所代表的意義。在語言學中，它主要是研究這些標誌（如單詞，短語，或聲音）在語言中的意義。而在前端開發領域，語意主要涉及的是HTML元素、屬性和屬性值（包括像Microdata這樣的擴充）所約定的意義。這些在規範中常用的正式約定語義，可以幫助程式（以及後來參與開發的人）更好地理解一個網站各方面的資訊。然而，即使這些元素、屬性和屬性值的語意是正式化的，它們依然得服從於開發者的適應程度以及共同選擇的結果。這使得正式的約定語意也可能在未來被修改（而這正是HTML設計原則之一）。
區分不同類型的HTML語意
遵守編寫「語意化的HTML」這個原則，是現代專業前端開發的基礎之一。絕大多數的語意都與目前或預期的內容性質有關（如：h1元素，lang屬性，type屬性的email值，Microdata）。
然而，並非所有的語意都需要以內容為導向。類別名稱不能“無語義”。不管是用什麼名字命名，它們都必須有意義與目的。類別名的語意可以和那些HTML元素不同。我們可以藉助HTML元素、某些HTML屬性、Microdata等所具有的「全域性」語義，然後利用網站或應用的「局部性」特定語意加以區分，這些特定語意通常包含在屬性值中，例如class屬性。
儘管在HTML5規範的class屬性這一章節中重申了這個假定的「最佳實踐」…
…鼓勵開發者使用class屬性值來描述實際內容，而不是描述期望展現的內容。
…並沒有什麼內在的原因非這樣做不可。事實上，當這種方法在大型網站或應用程式中運用時，它往往會成為一種障礙。
HTML元素和其它屬性已經提供了內容層的語義
對於機器或訪客來說，類別名稱所能透露的有用的語義資訊非常少，甚至沒有。除非它是已經約定好的那一小部分名稱（機器同樣可讀） —— Mircoformats
類別名稱的主要用途是成為CSS和JavaScript的鉤子。如果你不需要為你的頁面添加表現和行為，那麼你或許不必在你的HTML裡添加類別名稱
類別名稱應該為開發者傳達有用的訊息。當你閱讀一個DOM片段時，它將有助於理解某個類別名稱的具體作用。尤其是在多人協作的開發團隊裡，與HTML元件打交道的可不光只有前端開發者。
舉一個很簡單的例子：
當內容還不明顯的時候，這個類別名稱news不能告訴你任何事。它沒有向你提供關於這個組件整體結構的信息，而且一旦內容不再是“新聞”時，使用這個類名就顯得非常不妥。類別名的語意過度貼近內容，架構既不容易擴展，也不容易為其他開發人員所用。
與內容無關的類別名稱
從某個設計模式的結構與功能中提取類別名稱的語意是一種更好的方法。那些類別名稱與內容無關的元件可重複使用性較高。
我們不應該害怕讓各層之間的關係變得清晰而明確（這裡應該是指結構層、內容層等，譯者註），而不是用類名嚴格地反應明確的內容。這樣做不會使類別名稱“無語義”，這只是表明它們的語義並不取決於內容。我們也不應該害怕使用額外的HTML元素，只要它們能幫助你創造出更強壯、更靈活且更具重複使用性的元件。這樣做不會使HTML變得“無語義”，這僅僅意味著你標記內容所使用的元素數量超過了最小值而已。
前端架構
元件、模板、物件導向的體系結構的目的是能夠開發出一種數量有限的可重複使用的元件，它可以在一定範圍內包含不同的內容類型。在大型的應用程式中，對類名語義來說最重要的事情是，能夠用實用主義服務於它們的主要目的—— 提供有意義的、靈活的、可重複使用的表現或行為的鉤子供開發者使用。
可重複使用且可組合的組件
總的來說，可擴充的HTML/CSS必須依賴HTML中的class，以便建立可重複使用的元件。一個靈活的、可重複使用的元件，既不依賴DOM樹的某一部分，也不需要使用特定類型的元素。它應該能適應不同的容器，並且可以輕鬆更換主題。如果有必要，額外的HTML元素（超出標記內容所需的元素之外的元素）可以讓元件更強壯。 Nicole Sullivan所說的media object就是一個很好的例子。
避免用類型選擇器支援class，可以讓元件更容易合併。下面這個範例中，btn組件與uilist組件不易於合併。問題在於.btn的權重比.uilist a要小（這將覆蓋任何共享屬性）。而且ulist元件需要錨點作為子節點。
一種讓uilist元件與其它元件輕鬆組合的方法是，uilist的子級DOM元素用class來加入樣式。儘管這會降低權重，但是它的主要好處在於，它為你提供了處理子節點的任何結構樣式的選擇權。
在你修改組件的結構或樣式的時候，可能會不經意間對那些必要的JavaScript行為和復雜的功能造成影響，用這種方法的話，可以降低這種可能性。
組件修改器
組件常常會有一些變體，它們與基本組件只有細微的差別。例如，不同的背景色或邊框。主要有兩種創建這些組件變體的模式。我將它們稱為“單類名”模式和“多類名”模式。
單類名模式
多類別名稱模式
「多類別名稱」模式意味著，你只需要使用一個單獨的元件內部選擇器，便可以改變所有類型的btn元素的樣式。 「單類名」模式意味著，你必須顧及所有可能的按鈕類型，並在創造一個新的按鈕變體時調整這個選擇器。
結構化的類別名稱
當創建一個元件時－並為此增加了「主題」－其中一些class被用來區分各個元件，有些class被當作元件的修改器，其它的class則用來關聯DOM節點，它們一起被包含在一個較大的抽象組件中。
很難去判斷btn（元件）、btn-primary（修改器）、brn-group（元件）和btn-group-item（元件子物件）之間的關係，這是因為這些名字不能清楚地表現class的目的。沒有一致的模式。
在過去的一年中，我一直在嘗試命名模式，目的是能幫助我快速理解在一個DOM片段中節點的表象之間的關係，而不用為此來回切換HTML、CSS與JS文件拼湊網站的架構。這種模式主要受到BEM系統的命名方法的影響，但被改編成一種我認為更容易瀏覽的形式。
component-name
component-name--modifier-name
is-state-type
js-action-name
js-component-type
我將一些結構當作抽象的「模板」來處理，其它的則視為更清晰的組件（通常建立在「模板」上）。但是這種區分並非總是必要的。
這只是我目前發現的一種有用的命名模式。命名模式可以是任何形式。但這種命名模式的好處在於消除了模糊的類別名，只依賴（單）連接符，或是下劃線，或是駝峰格式。
Nicole Sullivan的言論
中經常會提到文件大小的存儲（以及維護改進），並提到了像Facebook這樣的公司採用這種方法的經歷。進一步的，我想我會分享我在預處理輸出時的HTTP壓縮效果，以及大量使用HTML類別的一些事情。當Twitter Bootstrap剛問世的時候，我重寫了已編譯的CSS，以便更好地與手動操作的檔案比較大小。在最小化所有的檔案之後，手動操作的CSS檔案比預處理程序輸出的小10%。但是當所有的檔案都通過gzip壓縮後，預處理程式輸出的CSS檔案比手動操作的小了5%。
這強調了比較HTTP壓縮後檔案大小的重要性，因為減少的檔案大小並不能說明全部問題。它暗示了有經驗的CSS開發者在用預處理程序時不必太過關注編譯後的CSS中一定程度的重複，因為它將在HTTP壓縮後變得更小。透過預處理程序處理更易於維護的CSS程式碼所帶來的好處，要勝過關注原始CSS和壓縮後輸出的CSS的美觀或檔案大小。
