為了友善大家了解，我将這10個糟糕用法歸為三大類：權重、工作流、自以為是。
css 中的權重取決于你如何使用具體的css 規則。
#layout #header #title .logo a { display: block; }
看看上面這串 css 選擇器，你可能覺得這是一段符合語義化的「好」選擇器：簡單明了。如果你依照習慣從左往右讀，你可能是這麼了解：「先找到主要布局區域，再找頭部區域，再找倒 title 标題區域，再找到 logo 标志區域，再找到這裡面的所有 a 錨點」，對于 css 來說，這是一個很具體的精确定位，但是，實際上我們很少有機會需要這麼精确的定位。過大的css權重會造成你的樣式表更加難以維護(你考慮過接你班的同僚的感受木有！)，也更加難以閱讀和了解(這麼多層聲明、一長串你鬧哪樣啊)。
01.濫用 id
css 權重的高低取決于你使用什麼樣的選擇器：id,class 類,tags 标簽。舉個栗子：
來做這麼一個小測試，有這麼一個超連結如下，如果我們沒有其定義其他樣式，浏覽器渲染出來的最終結果會是什麼顔色？
最終的顔色會是紅色，因為 id 屬性是三者之中權重最高的(id在網頁中隻能使用一次，他得權重值為100)，是以紅色葫蘆娃成功擊敗了其他娃娃，舉起了栗子。
根據 css 權重，權重次于 id 的是class類，最後才是tag标簽，正如你如上圖審查器中所看到的。
當然啦，像上面我們舉的栗子這種「同時使用 id/calss/tag 」的情況在實際應用中還是很少見的，在日常開發中，我們更多的情況是會遇到如下情況：
假設這是我們的一個項目，現在我們決定要把一個在 header 的 link設定成無邊框，随手一寫，我們添加了：
然後再在 html 中添加了一個 special-link 的class 類，這下解決我們的問題了嗎？ 答案是：沒有！ 由于 id 的權重如此之高，我們需要更高權重的聲明才能實作我們的需求。下面這樣寫才是正确的：
假如說這種情景在我們的 code 過程中不斷地出現：設定 header 區域另外一個特殊的超連結 link 為某特殊的樣式，你該怎麼處理呢？ id 的高權重特性意味着濫用 id 絕對是一個很糟的做法！
那我們如何解決這個問題呢？用 class 類來代替 id 吧。
02.大串的 css 選擇器(多層級)
上面這個栗子不僅僅亂用 id，他還很長，正如同亂用 id導緻的高權重麻煩，如果你使用一大串選擇器(超過三個層級)你同樣會造成過高權重，導緻你陷入到高權重和更高權重的汪洋大海之中。
那針對這個問題的解決辦法有什麼呢——精簡！如同我們現在這個栗子，如果我們用一個 .logo class類就能解決我們的需求，那我們就沒必要寫這麼以大串了。一般情況下，我們應該控制選擇器在2個，最多3個。
03.inline styles
内聯樣式是css 權重罪惡的源泉，同時也從根本上摧毀了我們使用 css 的初心(結構樣式分離)。當我們的工程師好不容易走出 tables 的魔窟開懷擁抱外部樣式表，我們早就應該知道不要把樣式同結構混雜在一起。
根據 css 權重級的特性，内聯樣式隻能被!important 所覆寫。一般來說，這就意味着，如果某猿使用了!important，他們更多是被逼的沒辦法才這麼用(對應英文 reactive)，而不是想這麼用(preoactive)。的确!important在 css 樣式表中用起來十分友善，但我們最好是聰明地、小心翼翼地碰她、用他，而不是把他當做救命稻草(救命稻草用多了，遲早也會從救命稻草變成壓死駱駝的稻草)。
下面舉例怎麼解決内聯樣式的問題，就兩步 1.複制删除 2.粘貼 。剔除内聯樣式，轉移到樣式表之中吧。
04.從上至下式的粗放命名
說完 css 權重，接下來我們來談談其他 css 的糟糕用法。假設我們開始了一個新項目，設計師丢給我們一份 psd，我們開始在 html 中寫基本的架構。
根據結構從下至上式的命名方式模糊化了 html 結構，工程師常常根據上下結構來命名id 和 class，而不是具體的設計元素，例如#header,content，這常常會導緻長選擇器(舉個例子如. menu ul li a｛ ｝)，這樣的後果是我們的代碼變得難以調試和維護。怎麼解決這個問題呢？我們應該嘗試從網頁中分離出設計元素，這同樣可以減少我們代碼中的備援。
05.備援/重複
備援意味着你寫 css 的過程中不斷重複某些代碼。在使用程式設計語言的時候， 我們很好了解重複(造輪子)意味着浪費時間，我們在 code 中應該遵循 dry 原則(don’t repeat yourself)。什麼情況下我們會重複造輪子呢？舉個栗子：
實際上，我們可以有個更好的解決辦法
比如說我們要添加一個不同顔色的标題，我們可以使用一個常用的命名，或者添加一個具體的 class 類。
在 sass 之中，你可以使用@extend 繼承選擇器，被繼承的選擇器的樣式也被繼承。這個特性使得我們可以很友善管理不同的樣式，舉個栗子：
當css預處理編譯器将.scss轉換成.css檔案時，我們最終輸出的樣式是：
最終輸出的是一模一樣的效果，解決重複和備援的問題，要求我們在寫 css 的時候心中對 html 層級結構要有個大緻的規劃，思考不同的設計元素之間的層級和關系，我們規劃得越清晰，最終輸出的 css 也越精簡。
06.精簡你的機關
)，學習一點相關知識對我們提高代碼可維護性至關重要。
下面我們進入到這篇博文的第三也是最後一個部分「自以為是」，這些壞習慣包括：增加不必要的東西，錯誤，無意義的 css。
07.向下相容和無效的規則
在開發的過程中，如果你不需要使用 css3 之類的高大上代碼就能實作效果，那再好不過了。可是，作為工程師的你在 chrome 最新版本上面看到的效果，并不意味着你的使用者能在他們的浏覽器上看到同樣的效果(考慮過 ie 的感受沒有)，一個十分糟糕的壞習慣就是完全忽略向下相容性。
08.(沒有意義)不起作用的樣式
roberts 推薦的重構精簡方法是删掉屬性為0和none的屬性值。
如果你像重構之前的那樣寫法，h2是一個我們在web 設計中會不斷重複用到的元素，這個本質上「你寫了更多的代碼卻沒有實作了更少的樣式效果」，如果我們接下來又要設定一個h2的屬性為其他樣式，那代碼會得很亂。
09.巧而不巧:用 hack 不意味着你是個好 hacker
負的 margin 邊距，!important等等，上面的這些就是我們所說的 hack 用法(此 hack 非針對ie 相容的 hack，也可以了解成 cheater 作*弊*用法)，如果其他人問我們為什麼要這麼寫？我們可能隻需要回答「管他呢，反正能實作效果」。
當我們為自己使用這些充滿「弊」端的方法而略不放心的時候，一個解決辦法就是把我們的這些 hack 放到一個特定的樣式表檔案hack.css之中。
任何時候你意識到你寫了一個 css 的 hack 用法的時候，你直接把這些代碼放到這個hack.css 之中(或者樣式表的特定區域：通過注釋跟其他樣式區分開)，這個專屬區域是個好解決方案因為他最終會在使用者端隐藏。
當我們養成了這個習慣，我們可以十厘清晰地知道我們寫了哪些 hack ，同樣可以友善我們了解我們使用這些 hack 的情景，讓我們可以知道如何避免這些 hack 。我們有許多寫 hack 用法的理由，但是如果我們不記錄我們為什麼 hack，我們将不會從我們這些 hack 中學到我們為什麼要錯誤地這麼用。
10.糟糕的文檔和注釋
昨天在微網誌上看到一個段子「程式員最讨厭的四件事：寫注釋、寫文檔、别人不寫注釋、别人不寫文檔 …」。
css_doc 跟 javadoc類似，他的轉換原理基于 cssdoc. kss(knyle style sheets)，對于前端和設計師來說都十分有益。
在這篇文章中，我們介紹了一些常見的 css 糟糕用法，指出了為什麼我們應該避免這些用法和應該使用什麼正确的用法。還是這句話”doin something is always better than nothing”，行動起來總比什麼都不做要好點，未雨綢缪有備無患。
今天你看完這篇文章，知道了10個糟糕的 css 用法，這不意味着你明兒去上班就把你過去所有的代碼都重構一遍。從點滴開始，一步一步來才是我們開發工作的正确做法。在接下來的工作中，注意這些細節，避免這些「小」錯誤，讓我們的代碼更漂亮點。終有一天，我們會發現”code is poetry”。
本文章轉載自http://www.creativebloq.com/css3/avoid-css-mistakes-10135080