看某前端設計書上說，在 base.css 里先定義一些基礎樣式然後在 html 裡面加上相應的 class，這樣是否和語義化相矛盾？

01-14

比如： .w100{width:100px;}.w200{width:200px;}.w300{width:100px;}.m100{margin:100px;}.m200{margin:200px;}.m300{margin:300px;}……
我的理解是：既然標籤要語義化那class，id應該也是語義化的而不是完全淪為為樣式服務的，誠然這樣做很方便

我想你指的.w100等應該指的是基礎樣式文件（如base.css）裡面的通用原子類吧？

這個問題問的很好。

請先閱讀彬GO的文章《CSS代碼命名慣例語義化的方法》http://blog.bingo929.com/css-coding-semantic-naming.html

另外再請參閱本人的文章《再談語義化》http://ued.ctrip.com/blog/?p=2735

語義化分為html標籤的語義化和css命名的語義化，你這裡指的是CSS命名的語義化。

.w100定義了寬度為100px的通用屬性，可以很方便的掛在需要寬度設為100的模塊上。但讓我們來考慮一下一旦需求發生變更，寬度要改為200呢？或者改為250？這時你是去修改原型html里的類名？明顯這與我們的初衷不吻合。既然我們將CSS單獨放在一個文件中，我們的期望就是為了易於維護，樣式與html分離，一旦外觀樣式發生變化，我們可以最少程度的去修改原型文件，而直接通過修改樣式即可解決。

彬GO的一句總結很好：語義化命名，而不是結構化命名。（目前看來欠妥）

當然，這種方法最大程度的抽象出了通用屬性，可以節省一定的CSS冗餘代碼，但這僅僅適用於後期變更很少的項目，即確定了此模塊為100後期基本不會變化的情況。

還是一句話，前端技術沒有銀彈，沒有最好的方法，只有最合適的方法。

--------------------------------

PS:感謝@賀師俊指出，的確「結構化命名」欠妥，因為還有可能是諸如"color-red"這類型的通用原子類，而「結構化命名」僅僅指的是CSS的框模型的命名。希望沒有誤導大家。「樣式描述命名」顯得更合理一點。

沒錯，這樣做是違背語義化的要求的。我已經批判過這種流傳甚廣的anti-pattern多次了。請順序閱讀這幾篇blog：

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

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

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

不知道是什麼書上寫的，實在不知道.w100{width:100px;}這個意義是什麼，這個類做了什麼抽象？如果寬度變成150，類名不改成w150嗎？這樣做還要這個原子類有什麼用呢？

類名和id名是需要語義化的，如果你的產品中發現需要這樣的純表現化的類，那麼我覺得是沒有設計好。

個人認為這樣的做法的確是把樣式名稱和 HTML 結構做了很深的耦合，但是開發維護是需要效率的，不是一味的追求純粹的語義化和解耦，最終的方案都是權衡的結果。我們要明白設計開發最終的目的是什麼。

這是一個比較蛋疼的問題，這種寫法確實可以減少代碼量，但需要很多人員的配合，比如視覺，而且需求要確定下來，萬一需求修改了，那麼祝賀你。。。所以慎用

多人維護的時候可以做到一目了然，不過實際上不太好：

比如這個 .m100 ，我如果在實際中要改成 margin: 110px 該怎麼辦呢？

是不是要把所用到的 .m100 全部替換成 .m110 呢，或者只改了 css 中的內容而不改名稱？那樣不就歧義了么。

我的建議（當然名字你可以隨便起）：

.w100 -&> .w-narrow

.w200 -&> .w-normal

.w300 -&> .w-wide

.m100 -&> .m-near

.m200 -&> .m-normal

.m300 -&> .m-far

這樣既能在部署時保持一目了然，又能做到可以靈活修改。

---------------

個人理解，所謂語義化是為了更好的理解和維護代碼服務的，並不是強制性的（而且只是針對HTML）。

在盡量高效美觀的前提下，你的id和class只要不是 div1、div2、div3 這一類毫無意義的符號就好了。

語義化只跟HTML內容及URL地址有關，主要是指head標籤里的內容、及BODY標籤里的內容的標籤名、層疊關係和順序。

語義化與CSS、class的命名沒有關係，跟JS也沒直接關係（除了AJAX為主的網頁在GOOGLE是有用URL中的hash地址來進行定位之外）。

話說關於前端模塊化的問題，我之前就蠻想探討一下，不過沒想到有人盡然問了，那我也順便分享下自己的一些看法：

為什麼需要CSS語義化？既然要用的話，你至少要知道原因吧，總不能因為「XX書上說要這樣用」，所以我也這樣用。個人認為是在CSS發展的初期，部分人喜歡用「樣式信息」來為選擇器命名，也就是用例如redBox，floatArea。這樣的話，很明顯是不太能滿足開發的需要的，也就是 @interjc 同學提到的，後期可能會更改需求。所以，後來大家都開始建議用比較語義化的選擇器，這樣，一方面即使更改了需求，另外一方面，語義化畢竟是htmlcss發展的趨勢，也算是為後期鋪路（其中做得「最語義化」的應該就是微格式：http://microformats.org/，有興趣的可以google下相關的）。
為什麼要用模塊化寫法？我記得以前看過一本《Web前端開發修鍊之道》（http://book.douban.com/subject/4881987/）的書，作者貌似是當時新浪前端的大牛，他在裡面就提到了用.mt10，.fl等選擇器來將一個「語義化的選擇器」拆分，這樣可以減少整體的代碼量。除此之外，可以將大型網站的css利用MVC的設計思想，分為比較模塊化的結構。
模塊化寫法和css語義化是否衝突？個人比較認同@顧軼靈，按照個人比較直白的話，就是這個意思：不要單純追求「語義化」，你學到的相關知識都是為項目服務的。
我目前個人的項目經驗，使用這種模塊化寫法並不和語義化相衝突。我一般會在比較大的區域上用語義化寫法，而在嵌套不超過兩層的標籤上用模塊化寫法。因為現在每個項目，開始做的和最後成型的總是有差別的（也就是前面@火柴同學說的），而且作為一個前端開發工程師，你到後面能改的，主要還是CSS（html如果已經和後台相關代碼嵌套，要改的話多少會有點麻煩），如果完全用模塊化寫法，根本無法滿足後期的需求；如果完全用語義化寫法，會增加多於的選擇器（比如有個地方只是要把那個字顯示成紅色）。

有點太極端了就不好了，如果項目定型了，很少去動，可以用這樣的，如果項目變動大，改起來太麻煩！有利有弊，以前有過這樣的教訓，所以，建議保留常用的幾個，沒必要w1到w100什麼的，太碎了，很多都用不到！

問的問題跟語義化無關，命名規則而已。

其實還是要根據項目來，並不能絕對說這種方法好或者不好。

比如那種需要很快輸出，基本不需要要後期維護的項目，（例如活動頁，新聞頁等）。那這種預先定義樣式的方法效率就很高。

而那種有大把時間死扣優化，或者體量很大需要精細維護的項目，還是模糊命名比較合適。

bootstrap基本上是屬於前者的。

就像前面知友所說的，沒有對不對，只有合適不合適。

這種方法其實挺好，最流行的css框架960就是採用類似的方法。