原文地址羅磊的獨立博客:「網頁重構應該避免的10大 CSS 糟糕用法」
對於網頁重構來說，CSS禪意花園 是網頁佈局從 table 表格轉到了 html +css 的標誌 。這些年來，隨着我們的網站越來越複雜：html5，css3，新的技術、新的屬性，越來越多的開發者開始思考和嘗試提高他們的 CSS 技能。那麼我們從哪裏着手呢？對於網頁重構
工作來說，我們應該養成什麼樣的開發習慣？一個糟糕的 css 用法是怎樣的？我們應該怎麼處理這些糟糕的 css。今天這篇文章，我將談一談10個我們應該避免的 css 糟糕用法，當然，我們也會分享怎麼纔是正確的用法。
爲了方便大家理解，我將這10個糟糕用法歸爲三大類：權重、工作流、自以爲是。
權重！權重！！權重！！！
正所謂馬太效應，如果你寫了很爛的
css，這段爛代碼的不好之處是他會導致更多和更爛的代碼。如果你需要解決一個 css bug，發現唯一的解決方法是：使用更多層級的選擇器、 id 選擇器；甚至更糟糕：使用內聯樣式( inline-style )，直到使用最後的大殺器!important。以上提到的所有用法歸根到期他們犯了「過多權重」的錯誤。
CSS 中的權重取決於你如何使用具體的css 規則。
#layout #header #title .logo a { display: block; }
看看上面這串 CSS 選擇器，你可能覺得這是一段符合語義化的「好」選擇器：簡單明瞭。如果你依照習慣從左往右讀，你可能是這麼理解：「先找到主要佈局區域，再找頭部區域，再找到 title 標題區域，再找到 logo 標誌區域，再找到這裏面的所有 a 錨點」，對於 css 來說，這是一個很具體的精確定位，但是，實際上我們很少有機會需要這麼精確的定位。過大的css權重會造成你的樣式表更加難以維護（你考慮過接你班的同事的感受木有！），也更加難以閱讀和理解（這麼多層聲明、一長串你鬧哪樣啊）。
01.濫用 id
CSS 權重的高低取決於你使用什麼樣的選擇器：id,class
類,tags 標籤。舉個栗子：
#my-link{color: red} .my-link{color: yellow} a{ colour: blue}來做這麼一個小測試，有這麼一個超鏈接如下，如果我們沒有其定義其他樣式，瀏覽器渲染出來的最終結果會是什麼顏色？
<a href="#" id="my-link" class="my-link">舉個栗子</a>最終的顏色會是紅色，因爲 id 屬性是三者之中權重最高的（id在網頁中只能使用一次，他得權重值爲100），所以紅色葫蘆娃成功擊敗了其他娃娃，舉起了栗子。
根據 css 權重，權重次於 id 的是class類，最後纔是tag標籤，正如你如上圖審查器中所看到的。
當然啦，像上面我們舉的栗子這種「同時使用 id/calss/tag 」的情況在實際應用中還是很少見的，在日常開發中，我們更多的情況是會遇到如下情況：
#header a { border:2px dashed #000 }假設這是我們的一個項目，現在我們決定要把一個在 header 的 link設置成無邊框，隨手一寫，我們添加了：
.special-link { border:none }
然後再在 html 中添加了一個 special-link 的class 類，這下解決我們的問題了嗎？ 答案是：沒有！
由於 id 的權重如此之高，我們需要更高權重的聲明才能實現我們的需求。下面這樣寫纔是正確的：
#header .special-link { border: none }假如說這種情景在我們的 code 過程中不斷地出現：設置 header 區域另外一個特殊的超鏈接 link 爲某特殊的樣式，你該怎麼處理呢？ id 的高權重特性意味着濫用 id 絕對是一個很糟的做法！
那我們如何解決這個問題呢？用 class 類來代替 id 吧。
02.大串的 css 選擇器（多層級）
#header #title .left-side img.logo { opacity: 0.5 }上面這個栗子不僅僅亂用 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)。什麼情況下我們會重複造輪子呢？舉個栗子：
.some-title { font-weight: bold; } .some-other-title { font-weight: bold; color: red }實際上，我們可以有個更好的解決辦法
.some-title, .some-other-title { font-weight: bold; } .some-other-title { color: red; }比如說我們要添加一個不同顏色的標題，我們可以使用一個常用的命名，或者添加一個具體的 class 類。
<h3 class="some-title pop">我的標題/h3>
這個有點面向對象的CSS的思想在裏面，使用
Sass 中的 @extend 特性可以很好地解決我們這個問題。
在 Sass 之中，你可以使用@extend 繼承選擇器，被繼承的選擇器的樣式也被繼承。這個特性使得我們可以很方便管理不同的樣式，舉個栗子：
.some-title { font-weight: bold; } .some-other-title { @extend .some-title; color: red; }
當CSS預處理編譯器將.scss轉換成.css文件時，我們最終輸出的樣式是：
.some-title, .some-other-title { font-weight: bold; } .some-other-title { color: red; }最終輸出的是一模一樣的效果，解決重複和冗餘的問題，要求我們在寫 css 的時候心中對 html 層級結構要有個大致的規劃，思考不同的設計元素之間的層級和關係，我們規劃得越清晰，最終輸出的 css 也越精簡。
06.精簡你的單位
如果你的樣式表中混雜着 px,em,rem等等單位，是時候改變了，業內著名的web開發者Rachel
Nabors 呼籲大家統一使用em爲字體大小單位，他曾說「我看其他人的樣式表第一件事就是看字體樣式，然後把所有的font-size的單位換成em」，這幾年用戶使用的終端越來越多樣（不同的終端、不同的瀏覽器使用的默認字體大小存在差異），使用絕對字體大小px變得越來越不可控，使用em等相對大小的字體則避免了這個問題。
如果你想在轉成em對這些單位有個深入點的瞭解，推薦你閱讀《CSS文字大小單位PX、EM、PT》。
當然，如果你就是不喜歡em和他們嵌套特性，那麼你可以更進一步瞭解 CSS3 中推出的新單位 rem。
不同單位在 web 設計之中的戰爭還在繼續（可參考文章CSS Font-Size: em vs. px vs. pt vs. percent ），學習一點相關知識對我們提高代碼可維護性至關重要。
下面我們進入到這篇博文的第三也是最後一個部分「自以爲是」，這些壞習慣包括：增加不必要的東西，錯誤，無意義的 css。
07.向下兼容和無效的規則
在開發的過程中，如果你不需要使用 css3 之類的高大上代碼就能實現效果，那再好不過了。可是，作爲工程師的你在 Chrome 最新版本上面看到的效果，並不意味着你的用戶能在他們的瀏覽器上看到同樣的效果（考慮過 IE 的感受沒有），一個十分糟糕的壞習慣就是完全忽略向下兼容性。
如果你在項目中使用rgba()，你是否測試過這個屬性的兼容性？如果沒有，那你最好祈禱沒有 IE8的用戶會訪問你的網站。你是否寫全了針對不同瀏覽器的不同的規則（-webkit,-ms
-moz 等等）？解決這個問題，可以使用 CSS
LInt檢測下你的 css 代碼，CSS Lint的檢測規則包括錯誤的和不合理的地方。
08.(沒有意義)不起作用的樣式
Harry Roberts的Code smells in CSS是關於 css 糟糕用法的經典文章。他舉了幾個可有可無的不起作用樣式的栗子：
h2{ font-size:2em; margin-bottom:0.5em; padding-bottom:0.5em; border-bottom:1px solid #ccc; } .no-border{ padding-bottom:0; border-bottom:none; }
Roberts 推薦的重構精簡方法是刪掉屬性爲0和none的屬性值。
h2{ font-size:2em; margin-bottom:0.5em; } .headline{ padding-bottom:0.5em; border-bottom:1px solid #ccc; }
如果你像重構之前的那樣寫法，h2是一個我們在web 設計中會不斷重複用到的元素，這個本質上「你寫了更多的代碼卻沒有實現了更少的樣式效果」，如果我們接下來又要設置一個h2的屬性爲其他樣式，那代碼會得很亂。
Harry Roberts是 inuit.css 框架的作者。
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。對於大部分語言（html,css,php,JavaScript） ，開發者可以直接在代碼文件中寫上註釋（文檔）。
Nabors 曾說「我曾YY：如果我今天寫完一個項目的
css 但是明兒我卻掛掉了，有一個人幸運地接手我這個項目，那他看得懂我的這些代碼是什麼意思嗎？」。儘量地讓我們的樣式表中的結構清晰，如果不能讓人立馬知道你的選擇器指的是哪裏的樣式，可以嘗試添加註釋（什麼！你還說註釋增加css
文件大小！難道你不知道壓縮工具麼！）。
第一步是在必須的地方做好註釋，第二步是使用工具把css文件中的這些註釋轉換成一個合適的文檔。推薦可以使用css_doc和KSS。
css_doc 跟 JavaDoc類似，他的轉換原理基於 CSSDOC. KSS（Knyle Style Sheets），對於前端和設計師來說都十分有益。
總結
在這篇文章中，我們介紹了一些常見的 css 糟糕用法，指出了爲什麼我們應該避免這些用法和應該使用什麼正確的用法。還是這句話"Doin something is always better than nothing"，行動起來總比什麼都不做要好點，未雨綢繆有備無患。
今天你看完這篇文章，知道了10個糟糕的 CSS 用法，這不意味着你明兒去上班就把你過去所有的代碼都重構一遍。從點滴開始，一步一步來纔是我們開發工作的正確做法。在接下來的工作中，注意這些細節，避免這些「小」錯誤，讓我們的代碼更漂亮點。終有一天，我們會發現"Code is poetry"。