（譯者注：你是否還在用”layout-985″”redBg”的類名？你是否很糾結定義什麼類名？ Chris Coyier提出了”描述而非定義”。他舉例了一些常用的類名，是否語義化，給出了自己的判斷和理由。但是在某些場景，如大公司，考慮到簡潔和方便維護，語義化要做一些犧牲。）
語義總是個火熱的話題。有些人時時刻刻在追求語義化，有些人教條地執著於它，而有一些人不知道這究竟是什麼。
我認為語義像標簽、類、ID、屬性（描述而不是定義內容）一樣和HTML密切相關。我們用典型的例子來描述。
<;div class="article">;
<;div class="article_title">;Smurf Movie Kinda Sucks<;/div>;
<;div class="the_content">;Not surprisingly, this weeks release of
<;div class="darkbold">;The Smurfs<;/div>; kinda sucks.<;/div>;
<;/div>;
<;article>;
<;h1>;Smurf Movie Kinda Sucks<;/h1>;
<;p>;Not surprisingly, this weeks release of
<;b>;The Smurfs<;/b>; kinda sucks.<;/p>;
<;/article>;
不管你是否准備好迎接HTML5，當你需要一個HTML元素來定義文章，那麼article標簽比div加上類名article好。文章的標題成了header內容變成鍛煉，加粗但不強調的標題變成了加粗的標簽。
但是，並不是所有的都這麼簡單。我們來看看一些類名的對比，關於語義或不語義我提出了我的觀點。
1<;div class="column_1">;<;/div>;
非語義化。這是典型的例子，幾乎每個CSS柵格框架都用這類的類名來聲明柵格。不管是”yui-b”、”grid-4″或者”spanHalf”，這些都更像是定義，而不是描述該內容。所以，我覺得這些都不是語義化的類名，但是我同時覺得，在基於浮動的柵格系統布局中，我們沒辦法廣泛地避免這點。
1<;div class="footer">;<;/div>;
語義化。footer是個抽象的內容，但是在Web設計中，已經被賦予了一定的意義。它是置於網站底部的模塊，通常包含導航，版權，作者信息等等。這個類名包含這麼一組信息，而並沒有描述它的內容。
如果你准備迎接HTML5，那麼footer元素是更好的選擇。對於所有的HTML5元素都是如此。（頭部header，而側欄應該用aside等。）如果你還沒使用HTML5（你最好有個很好的理由），那麼最好使用同等的類名。
1<;div class="largeText">;<;/div>;
非語義化。這是在定義，為什麼文本會是大的？來突出顯示？那麼”standOut”或“callout_text”會好一些，因為在下次改版的時候，你可能會選擇另外的方式讓這個文本更加的突出，而不是文本更大，那這個類名看起來就不會太尴尬。
1<;div class="priority-2">;<;/div>;
語義化。我和MailChimp的Jason Beaird 和Aarron Walter談過這點，他們就是這樣聲明不同層級的按鈕（類名更多的用”p1″..”p5″之類的）。更高曾記得按鈕可能是更亮更大，而低層級的按鈕可能是混於內容之中，比較平淡。不使用內容本身的樣式來聲明層級，就是語義化。這和h1、h2、h3的道理一樣。
1<;div class="copyright">;<;/div>;
語義化。如果每個類名都這麼簡單就好了！這個可以用於包含“tweets”、 “pagination”或“admin-bar”的模塊。這最後的一個”admin-bar”或者應該叫”admin-nav”，在Theoretical Redesign Future裡面提到，這不應該再是bar。
1<;p class="introp">;<;/p>;
非語義化。Dave Rupert有一次開玩笑說，這是他最喜歡的類名。定義頁面第一段的特別的樣式，這是很常見的場景，就好像概覽，把觀眾吸引到內容上。
如果你要很好的浏覽器支持，你可能會需要一些類名，我覺得”intro”比”introp”會更好一些（不要使用元素的名字）。更好的方法是，使用樣式來針對第一段如article p:first-of-type或h1 + p。
1<;div class="clearfix">;<;/div>;
非語義化。這是個非常常見的類名，這是個清浮動的技巧，該元素包含它的子級浮動元素，不讓它崩潰。但是，這個類名跟它的內容毫無關系，不可避免地不語義。Dan Cederholm推薦一個感覺比較好的類名”group”來替代（詳見他的書 Handcrafted CSS）。對我來說，考慮類名的語義化，這個元素包含很多的元素，所以成為”group”（描述而不是定義）。
1<;div class="left">;<;/div>;
非語義化。在後續版本中，你可能會把它放到右邊，太過特征化。
1<;div class="success">;<;/div>;
語義化。 這在混合詞匯中用得很好，混合詞匯的類名，其中一個詞是描述內容，而另外一個是描述內容的狀態，如”success message”，可以代表如”您的文件已上傳”之類的信息。如果信息是”上傳文件出錯”，那麼類名可以變成是”fail message”，然後有對應的樣式。
1<;div class="plain-jane">;<;/div>;
非語義化。這個類在定義某部分的內容應該有著不同的樣式。“plain-jane”想用來描述”normal”或”regular”。理想的情況是，CSS應該寫得更好，你不需要定義一個”regular”的樣式，而是通過繼承來實現，而對於那些更加突出的內容則用特別的樣式。
1<;div class="entry-unrelated">;<;/div>;
非語義化。Readability，是個Web 應用程序，可以調整格式並網頁保存，便於閱讀。它使用這個類名來定義那些不需要包含在保存的網頁中的元素。我這裡說它不語義的原因是，這個類名在描述”不是什麼”而非”是什麼”。我希望有個其它的類名來表達這個目的。就如link當中的rel=nofollow，而不是內容。
1<;div class="hyphenate">;<;/div>;
非語義化。定義內容的行為，而不是描述它是什麼。
1<;a class="link" href="#">;<;/a>;
非語義化。鏈接不需要定義為鏈接，它本身就是一個鏈接，所以，這是不必要的。如果這個類名要定義的內容是要區別於其它的鏈接，那麼用描述型的方式會好一些，如”book-link”或者（尚有爭議的）”button”。
讓我們看看你有兩種文章樣式，你要分別定義它們。Movie Reviews 有藍色背景，而Breaking News 有紅色背景以及更大的字號。
一種方式是這樣：
1 2 3 4 5 6 7<;article class="movie-review">;
...
<;/article>;
<;article class="breaking-news">;
...
<;/article>;
另一種方式是這樣：
1 2 3 4 5 6 7<;article class="blueBg">;
...
<;/article>;
<;article class="redBg bigText">;
...
<;/article>;
如果我們有個投票，讓大家選哪個更加語義化，我打賭，一定是第一個贏了。它實踐了這個理念：描述而非定義。第二個的類名定義了藍色背景等樣式。讓我們假設Theoretical Redesign Future™不是理論上的而是實際的。設計Movie Reviews的樣式變成了綠色背景。那麼類名blueBg顯得不適宜了。然而movie-review是完全沒有問題，你只需要對它的樣式進行屬性或屬性值的修改就行。
但是這也並不代表第一個總是對的，要看實際情況。假設這個藍色應用在網站的很多地方，可能是頁腳或者側欄的樣式，那麼你會這樣寫選擇器：
1 2 3 4 5.movie-review,
footer >; div:nth-of-type(2),
aside >; div:nth-of-type(4) {
background: #c2fbff;
}
這樣很方便，因為你只要定義顏色一次。但是也可能比較復雜，就是每個選擇器又有它單獨的一些樣式，所以它們要分開，或許你會用另外的方法如下把選擇器分開寫：
1 2 3 4 5 6 7 8 9 10 11 12 13 14.movie-review {
background: #c2fbff;
/* Plus other stuff */
}
footer >; div:nth-of-type(2) {
background: #c2fbff;
/* Plus other stuff */
}
aside >; div:nth-of-type(4) {
background: #c2fbff;
/* Plus other stuff */
}
這樣CSS文件會比較有組織（不同的內容部分對應不同的樣式區塊），但是前提是重復聲明的代價。在CSS Summit上，Nicole Sullivan的一個演講中，她提出大公司聲明同樣的顏色有上千次，但是沒人用blueBg之類的類名。或者，你可以使用mainBrandColor或者secondaryFont來定義。我理解的是，這就是OOCSS。犧牲了語義化，為了更大的好處（代碼更加簡潔）。
希望看聽到你們的觀點。對於語義或不語義，是否重要，你們一定有很多的不同例子和不同的看法。
原文：What Makes For a Semantic Class Name?作者是Chris Coyier