網頁重構應該避免的10大 CSS 糟糕用法

時間 2019-11-14

標籤網頁應該避免 css 糟糕用法欄目 HTML 简体版

原文原文鏈接

對於網頁重構來講，CSS禪意花園是網頁佈局從 table 表格轉到了 html +css 的標誌。這些年來，隨着咱們的網站愈來愈複雜：html5，css3，新的技術、新的屬性，愈來愈多的開發者開始思考和嘗試提升他們的 CSS 技能。那麼咱們從哪裏着手呢？對於網頁重構工做來講，咱們應該養成什麼樣的開發習慣？一個糟糕的 css 用法是怎樣的？咱們應該怎麼處理這些糟糕的 css。今天這篇文章，我將談一談10個咱們應該避免的 css 糟糕用法，固然，咱們也會分享怎麼纔是正確的用法。php

爲了方便你們理解，我將這10個糟糕用法歸爲三大類：權重、工做流、自覺得是。css

權重！權重！！權重！！！

正所謂馬太效應，若是你寫了很爛的 css，這段爛代碼的很差之處是他會致使更多和更爛的代碼。若是你須要解決一個 css bug，發現惟一的解決方法是：使用更多層級的選擇器、 id 選擇器；甚至跟糟糕：使用內聯樣式( inline-style )，直到使用最後的大殺器!important。以上提到的全部用法歸根到期他們犯了「過多權重」的錯誤。html

CSS 中的權重取決於你如何使用具體的css 規則。前端

#layout #header #title .logo a { display: block; }html5

看看上面這串 CSS 選擇器，你可能以爲這是一段符合語義化的「好」選擇器：簡單明瞭。若是你依照習慣從左往右讀，你多是這麼理解：「先找到主要佈局區域，再找頭部區域，再找倒 title 標題區域，再找到 logo 標誌區域，再找到這裏面的全部 a 錨點」，對於 css 來講，這是一個很具體的精肯定位，可是，實際上咱們不多有機會須要這麼精確的定位。過大的css權重會形成你的樣式表更加難以維護(你考慮過接你班的同事的感覺木有！)，也更加難以閱讀和理解(這麼多層聲明、一長串你鬧哪樣啊)。react

01.濫用 id

CSS 權重的高低取決於你使用什麼樣的選擇器：id,class 類,tags 標籤。舉個栗子：css3

#my-link{color: red}
.my-link{color: yellow}
a{ colour: blue}

來作這麼一個小測試，有這麼一個超連接以下，若是咱們沒有其定義其餘樣式，瀏覽器渲染出來的最終結果會是什麼顏色？git

<a href="#" id="my-link" class="my-link">舉個栗子</a>

最終的顏色會是紅色，由於 id 屬性是三者之中權重最高的(id在網頁中只能使用一次，他得權重值爲100)，因此紅色葫蘆娃成功擊敗了其餘娃娃，舉起了栗子。程序員

根據 css 權重，權重次於 id 的是class類，最後纔是tag標籤，正如你如上圖審查器中所看到的。github

固然啦，像上面咱們舉的栗子這種「同時使用 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)，對於前端和設計師來講都十分有益。