來源：
在怿飛’s Blog的這篇文章裡，又將上面的屬性分成了三組：顯示屬性、自身屬性和文本屬性。在回復裡，inG補充這還和浏覽器的解析過程有關：浏覽器先對DOM定位，然後解析自身屬性，接著再解析內部對象。（沒找到相關的英文資料，有知情者還望告知）
在Mozilla官方，其實並沒有推薦任何CSS書寫順序。很可能是某個開發者在閱讀fantasai的這篇文章 mozilla.org Markup Reference 時，順便對fantasai的CSS源文件產生了興趣，因此才有了上面的發現。
字母排序
NETTUTS上時不時有些好文章，這不，前不久，Trevor Davis就分享了一篇：5 Ways to Instantly Write Better CSS. 這篇文章中，推薦CSS的屬性按字母排序。
優點是：簡單，任何人只要遵守，一看就明白。
缺點是：太簡單，缺乏邏輯性。比如position, left, top等，這種緊關聯的屬性，如果都按字母排序，書寫和維護起來都不方便。Andy Ford推薦的排序
Andy Ford是HTML和CSS方面的專家，最近寫了一篇文章：Order of the Day: CSS Properties. 文章推薦的CSS書寫順序為：
Andy的順序大體上和fantasai推薦的順序保持了一致，但細節上更具可操作性。
SitePoint上還有個很熱烈的討論貼：How do you order your properties within a declaration block?
我喜歡fantasai和Andy的書寫順序，但fantasai的順序中，“自身”屬性有點含混不清，Andy的則太細，難以記住。我覺得可以借鑒CSS 2.1 Specification中對CSS屬性的分類，將Andy的順序稍微調整下：
1. 影響文檔流的屬性（比如：display, position, float, clear, visibility, table-layout等）
2. 自身盒模型的屬性（比如：width, height, margin, padding, border等）
3. 排版相關屬性（比如：font, line-height, text-align, text-indent, vertical-align等等）
4. 裝飾性屬性（比如：color, background, opacity, cursor等）
5. 生成內容的屬性（比如：content, list-style, quotes等）
事情永遠沒那麼簡單，比如下面這些困擾：
1. 對於shorthand怎麼處理？比如 border: 1px solid red; 其中border-width是和盒模型相關的，但border-color是裝飾性的。如何組織呢？
2. 考慮到換膚功能，是否應該將color, background, border-color等和顏色相關的都放一塊？以方便以後修改。
3. 對於hacks如何處理？單獨放到css文件最後面，還是和hack的屬性緊挨著好？
4. 維護同事的css文件時，對於新增加或有修改的屬性，如何注釋？如何書寫？
5. 還有，考慮到CSS Sprite, 所有背景圖的選擇器都放在一起？不過這已經超出本文的話題了：CSS選擇器內屬性的順序和組織。
6. 更進一步的討論是：CSS文件內的結構組織，以及多個CSS文件的組織。
CSS命名規則：
Css和其他程序一樣，都是有作用域這個概念，有全局、類局部作用這些方式。
舉個例子：
p{background:#f00;}/* 作用域 ：全局 */
.div p{color:#000;}/* 作用域：div類中*/
介紹下Css幾種編寫方式和權重對比
1）標簽：權值為0,0,0,1
2）類：權值為0,0,1,0
3）屬性選擇：權值為0,0,1,1
4）ID：權值為0,1,0,0
5）important的權值為最高1,0,0,0
相信大家在編寫Css的時候，當項目比較大，內容比較多的時候，命名就是一件很頭痛的事情，而且一個塊裡面要表現不同狀態的樣式 ，這是有掌握命名規則是一把利器，能讓你工作起來事半功倍。大致如下：（轉載自：http://www.cssforest.org/blog /index.php?id=143，大家可以去這裡看，比較多的技術文章）
要避免當狀態改變時名稱失去意義，最常見的就是用於布局的類名，如“left”、“right”，當左邊欄不再是左邊欄的時候，“left”這個名就沒有實際意義了。這與我們所推薦的 “命名要有意義”就相違背了，使用序號就更加有問題了。好像沒錯，不過有好長一段 時間都有個問題讓我很煩惱，如果一個頁面中同個模塊出現一次以上，而且細節還不一樣，那後面出現的名稱應該叫什麼呢？難道“one”、“two”就不是序 號？其實我們要避免遇到的情況就是當狀態（表現）改變時，對應定義的類名不會失去意義。
中文解釋 命名 中文解釋 命名
文本輸入框 .input_tx 段落文本顏色 .c_tx_p
密碼輸入框 .input_pw 相冊彈出的設置層 .pop_set_photo
登錄密碼輸入框 .input_pw_login 日志設置成功提示 .hint_suc_blogset
文本顏色 .c_tx 公共提示 .hint_gb
問幾個簡單的問題，可以幫助我們完成命名：
1. “什麼類型的定義？”——是個輸入框，input。
2. “類型補充說明”——如果一個詞說明不清楚，那麼補充說明類型，文本輸入框，input_tx。
3. “在哪使用？”——定義要使用的位置在哪？首頁的搜索文本輸入框，input_search_index。
結合“模塊化”相關的方法去定義，其實所需要定義的名稱並不需要很多。 如：“hint_tx”表示提示模塊的文字定義，“hit_tx_hint”表示提示裡文字強調的定義，至於是改變顏色還是加粗，這個就看不同提示模塊的需要了。