CSS最佳實踐團隊開發

時間  2019-11-19
標籤 css 最佳 實踐 團隊 開發 欄目 CSS 简体版
原文   原文鏈接

　你有過多少次接手別人開發過的項目，卻發現做者的代碼思路一團糟嗎？或是你跟幾個團隊成員合做開發，他們每一個人都有本身書寫代碼的方式嗎？或是你從新回顧你多年前開發的項目，不記得當初是怎麼想的？ javascript

　　我老是遇到這種事情。事實上，我最近在修復供應商提供facepalm-inducing的css上花費了將近300個小時。這300個小時，使我充滿了挫敗感，不只是由於我本身，還有個人團隊成員的緣由。並且他佔用了本應該花費在新項目上的寶貴時間和資源 php

　　若是供應商在他的css中已經遵循了一些基本的指導方針。那麼將會爲他節省寶貴的時間和金錢，更不用說我會已更好的狀態去對待他。在本文中,你將學習書寫CSS的最佳實踐來幫助你避免不一致和冗餘;實際上,這樣制定標準,簡化了團隊開發的工做。 css

　　結構化 html

　　書寫好的css的基礎是有良好的結構。這樣的css能夠幫助我以及任何未來要更新這段代碼的人，更好的理解並快速定位到要找的樣式上。 前端

　　在開始寫樣式前，我先定義了一個css文件結構，根據頁面中不一樣內容部分劃分的區塊。一般，這些結構是每一個網站通用的: java

　　1.Header web

　　2.Navigation 數組

　　3.Main content 瀏覽器

　　4.Sidebar app

　　5.Footer

　　在個人樣式文件裏，我添加了必要的註釋，以標明每一個部分的樣式從哪裏開始

?
1
2
3
4
5
6
　　/*---GLOBAL---*/
　　/*---HEADER---*/
　　/*---NAV---*/
　　/*---CONTENT---*/
　　/*---SIDEBAR---*/
　　/*---FOOTER---*/

　　注意第一個註釋global的部分，他不是針對於網站的特定內容，而是針對網站上的通用樣式，例如佈局結構，以及標題、段落、列表和連接等基礎樣式。

　　在樣式頭部設置通用的樣式，有助於全站更好的繼續共有樣式，並在須要時覆蓋便可。

　　越多的css就須要越多的組織

　　在建立超大型的網站，處理至關多的css時，我就會給每一個區塊裏添加二級註釋。例如，在global裏我定義這樣的二級結構分類：

?
1
2
3
4
5
6
7
8
9
10
11
12
/*---GLOBAL---*/
  /*--Structure--*/
  /*--Typographic--*/
  /*--Forms--*/
  /*--Tables--*/
/*---HEADER---*/
/*---NAV---*/
  /*--Primary--*/       
  /*--Secondary--*/  
  /*---CONTENT---*/  
/*---SIDEBAR---*/  
/*---FOOTER---*/

　　一樣你也看到了我給NAV也添加了二級註釋，分別爲主導航和次導航。

　　事實上，對於不多css的小型網站，我一般是不使用二級註釋的。可是對於大型的css文件，二級註釋被證明是很管用的。

　　自由格式化

　　你使用的註釋格式徹底取決於你。以上你看到的例子是我和個人團隊很鍾愛的方式。也有些人喜歡用兩行定義他們的註釋格式：

?
1
2
/*   HEADER      
------------------------------*/

　　另外一些人使用特殊字符如‘=’，做爲搜索字符的標記:

?
1
2
/*   =Header      
------------------------------*/

　　一些人不使用二級註釋，他們用一種徹底不一樣的結構，不是根據頁面內容劃分，而是用元素的類型劃分如：headers，images，lists等等。關鍵是用你喜歡的格式去定義並一直這麼使用。

　　想根據內容元素劃分？沒問題。想要小寫註釋，那就去作。不想使用二級註釋縮進？那就不用.不喜歡連字符想用時間？ok。你只須要作對於你和你的團隊最有意義的事情就好。

　　交流注釋用法

　　咱們已經瞭解了註釋的結構，可是你應該就這如何使用註釋的問題跟你團隊的同事交流一下。

　　什麼時間，誰作了什麼

　　做爲團隊成員的一份子，頗有必要在團隊成員之間交流已經寫好的css文件的相關細節。在個人團隊裏，咱們在css文件的頭部添加了一些css文件建立和更新信息的摘要註釋。

?
1
/*----TITLE: Main screen styles | AUTHOR: EPL | UPDATED: 03/23/10 by EPL----*/

　　在處理多個樣式表時，頭部的信息是有用的。如一個屏幕，一個用於打印，一個用於移動甚至是關於ie的hack寫法。做者的信息讓團隊成員知道一旦css出了問題應該去找誰。而更新信息讓團隊瞭解誰最後作的更新以及更新時間。

　　至於你的摘要註釋，僅須要包含對你團隊有用的信息。若是你不須要做者信息，跳過。若是想要版權聲明加上。我甚至見過摘要裏面有地址和聯繫信息的。

?
1
/*---- IE6 screen styles (ie6.css)  Company ABC 1234 Avenue of the Americas New York, NY 10020 http://companyabc.com  Updated: 03/23/10 by EPL ----*/

　　顏色值

　　我遇到過的最有用的css註釋之一是網站用到的顏色值。

?
1
/*---COLORS: Green #b3d88c | Blue #0075b2 | Light Gray #eee | Dark Gray #9b9e9e | Orange #f26522 | Teal #00a99d | Yellow #fbc112---*/

　　顏色值在開發階段頗有用，節省你測試顏色和從其餘樣式裏查找的時間。你不須要知道這個十六進制值是否是藍色，你只須要找到這個顏色值，而後複製粘貼便可。

　　在個人團隊裏，咱們在css文件頭部添加通用的顏色值，要在全部樣式聲明和註釋前，摘要註釋後面添加。咱們也嘗試保持關鍵字儘量簡單方便維護，可是他到底有多複雜徹底取決於你。

　　格式也全取決於你。你可讓全部定義的顏色值放在一行顯示，也能夠把他們分紅多行顯示:

?
1
2
3
4
5
6
7
8
9
/*---COLORS      
Green #b3d88c      
Blue #0075b2      
Light Gray #eee      
Dark Gray #9b9e9e      
Orange #f26522      
Teal #00a99d      
Yellow #fbc112 
---*/

　　一樣，找到一個最好的有利於你須要的格式，一旦定義好就要保持他的一致性。

　　開發和調試

　　有時候在我開發的過程當中，不得不徘徊在個人css 和團隊其餘成員之間。而這時註釋就派上用場了。當我有時左思右想爲何css在ie下會有這樣的bug，我就只須要走開便可。

　　你或是你的同事作個筆記，包括可能的樣式，和沒有解決的困惑：

?
1
2
3
4
5
6
7
8
9
/*--//--Styling for link states is pending new changes from designer, please don't edit | EPL 03/23/10--\\--*/ 
a, a:link, a:visited {    
  color:#0075b2;     
  text-decoration:none;
}  
   
a:hover, a:focus, a:active {    
  color:#b3d88c;
} 
　　爲了讓他們不同凡響，我一般用一種不一樣於其餘註釋的格式，同時讓他們儘量的詳細。仍是使用最適合你的格式。</span>

　　不過記住，一旦你完成開發和調試工做，這些註釋就沒有用了。他們既不跟你的工做有關，也不跟你的css有關，他們的存在只會增大你的文件體積。

　　樣式重置

　　樣式重置已經很流行。他們出如今樣式文件的頭部，用來設置html元素在跨瀏覽器顯示的基本樣式:

?
1
2
3
4
5
6
7
8
9
10
11
12
/*---RESET---*/ 
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote,pre, a, abbr, acronym, address, big, cite,code, del, dfn, em, font, img, ins, kbd, q, s, samp,small, strike, strong,sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table,caption, tbody, tfoot, thead, tr, th, td {    
  margin:0;    
  padding:0;    
  border:0;    
  outline:0;    
  font-weight: inherit;    
  font-style: inherit;    
  font-size:100%;    
  font-family: inherit;    
  vertical-align:baseline; 
}

　　以上的例子摘自Eric Meyer的重置文檔，這個我也常常用。可是我傾向於去掉我用不到的標籤，我也建議你這樣作。好比個人團隊構建的網站裏面幾乎沒有<kbd>,也沒有<iframe>,<applet>或是包含以上的一些元素。

　　因此，我去掉這些元素選擇器。雖然在頁面加載或是文件體積上只有很小的不一樣，可是我感受這樣有助於，避免團隊成員間對於不使用的標籤的困擾。

　　若是我不想要覆蓋瀏覽器的內置樣式，我也能夠編輯重置樣式表，例如如何處理無序列表。在這種狀況下，我確保這些元素不包含在樣式表聲明裏。

　　不過，我應該澄清一下，css重置並不適用於全部人。你有不少不使用他的理由，這由你決定。若是你要重置樣式，要保持你的重置樣式表儘可能乾淨和特殊。

　　命名約定

　　最頭疼的事情之一是，遇到其餘人寫的css，並且是定義的類名和id名毫無心義的那種。例如像下面這樣：

?
1
2
3
4
5
6
.f23{    
  background:#fff;    
  border:1pxsolid#ff0;    
  font-weight:bold;    
  padding:10px; 
}

　　我根本不知道.f23是什麼意思。甚至更糟的是都沒有任何形式的註釋。我不知道.f23表明什麼內容。是標題？主要內容？仍是導航？

　　這種狀況，尤爲是對於大型網站，就可能浪費大量的時間去查找出現這個類名的標籤位置。若是做者用一個約定好的名字命名，如那些有意義的，那些基於內容的樣式的：

?
1
2
3
4
5
6
.alert {    
  background:#fff;    
  border:1pxsolid#ff0;    
  font-weight:bold;    
  padding:10px;
}

　　如你所見，類名.alert提供的上下文信息要比用一個隨機數組成的類名提供的信息多。

　　不只僅是上下文，有語意的命名還能夠節約時間。考慮到一個公司品牌的頻繁更換，若是你開發的css使用表現的類名而不是語義化的類名和id名，那麼在尋找、維護css時，你將比預期花費更多的時間。

　　例如，若是你給網站上一塊內容，定義一個bluebox的類名，使用了公司logo的藍色基調。而後公司重組了，他們如今用紅色基調的logo，這時你的.blueBox就沒有意義啦。因此你不只須要更新樣式表的十六進制顏色值，還須要修改標籤中的全部引用到blueBox的地方。

　　相反若是你用callOut做爲類名（或是一樣有意義的名字），你會省去手頭的不少工做量。

　　類名濫用

　　在css 的使用中，我傾向於能少則少的原則。不能由於你能夠給每一個元素指定類名，就意味着你就應該給每一個元素指定類名。

　　在我修復供應商糟糕的css過程當中，發現類名被濫用了，出如今許多原本不須要的地方。例如每個lable標籤就定義一個lable類名，每個form就定義一個form。可是咱們的設計和結構中只須要給一個form元素設置樣式，它裏面也只包含一個label元素。

?
1
2
3
4
5
6
7
8
9
10
11
12
form.form {    
  float:right;    
  margin:0;    
  padding:5px; 
} 
  
label.label {    
  clear:both;    
  float:left;    
  text-align:right;    
  width:145px;
}

　　由此產生的css自己和他形成的冗餘並不可怕，可怕的是他形成的困惑。做爲一個設計師看到了這個form類，可能猜測是否是其餘樣式表裏也定義了叫form的類名，而後去查找根本不存在的樣式，這就是我時間浪費的緣由。

　　類名不等於特異性

　　上面只是一個簡單的例子。一個我遇到的有關類名更瘋狂的例子是渴望給予元素特殊性

?
1
2
3
4
5
6
<div id="feature">  
  <ul>     
    <li><a href="#newServices">New Services</a></li>     
    <li><a href="#newProducts">New Products</a></li>  
  </ul> 
</div>

　　注意到tabs的類名應用到了上面結構中的每個標記？致使以下的css目錄列表:

?
1
2
3
4
5
div.tabs ul.tabs li.tabs {    
  float:left;    
  font-weight:bold;    
  padding:3px; 
}

　　對於li最簡便的解決方法應該是這樣：

?
1
2
3
4
5
#feature li {    
  float:left;    
  font-weight:bold;    
  padding:3px;
}

　　若是你的元素定義樣式不須要類名，那就不要用。用的太多類名，不只使你的結構和css很臃腫，也失去了他們在css 中的意義。

　　你也許注意到了在最後的例子中，我僅使用了# feature做爲選擇器而不是div#feature。只有在爲了區別其餘選擇器的狀況下，添加div才合適，不然只會給你的團隊帶來負擔。並且儘可能少用特殊的聲明，也爲往後覆蓋任何樣式提供方便。

　　多類

　　最後一點，我不喜歡多類，你也許還有印象。雖然我不提倡使用沒必要要，多餘的類名，可是對於經過多類保持元素表現的共用，我但是一個忠實的粉絲，然而可能有一些理解的不一樣之處：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
.announcement {    
  background:#eee;    
  border:1pxsolid#007b52;
  color:#007b52;    
  font-weight:bold;    
  padding:10px;
}  
  
.newsAnnouncement {    
  background:#eee;    
  border:1pxsolid#007b52;
  color:#007b52;    
  float:right;    
  font-weight:bold;    
  padding:10px; 
}

　　上面的兩個聲明，除了.newsAnnouncement多了一個浮動外，都徹底同樣。因此我大可像下面這樣而不是重複寫相同的樣式:

?
1
2
3
4
5
6
7
8
9
10
11
.announcement {    
  background:#eee;    
  border:1pxsolid#007b52;
  color:#007b52;    
  font-weight:bold;    
  padding:10px;
}  
  
.floatR {    
  float:right; 
}

　　而後給個人新聞內容添加兩個類名

?
1
<div class="announcement floatR">

　　可是且慢，我不是說過要根據約定好的名字而不是根據表現命名嗎？沒錯，可是凡事總有個例外。

　　是的，.floatR是一個表現類名，可是他適用於這種狀況，並且能夠用於其餘須要多類的狀況，因此這是個人團隊常用的方法。

　　分組選擇器

　　在個人300個小時的折磨裏，遇到的另外一個問題是徹底相同的樣式出如今多個樣式表裏，而惟一的區別就是聲明他們的選擇器不一樣：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#productFeature {    
  background:#fff;    
  border:1pxsolid#00752b;    
  float:left;    
  padding:10px; 
}  
  
#contactFeature {    
  background:#fff;    
  border:1pxsolid#00752b;    
  float:left;    
  padding:10px; 
}
  
#serviceFeature {    
  background:#fff;    
  border:1pxsolid#00752b;    
  float:left;    
  padding:10px; 
}

　　這不只使得css文件體積過於臃腫，也使維護成了噩夢。解決方法就是合併他們成一個樣式聲明：

?
1
2
3
4
5
6
#productFeature, #contactFeature, #serviceFeature {    
  background:#fff;    
  border:1pxsolid#00752b;    
  float:left;    
  padding:10px; 
}

　　如今若是要更新樣式只須要修改一個聲明而不是三個。

　　一行仍是多行書寫？

　　本文中出現的全部css實例都是用的多行的格式，每一對屬性和值佔單獨一行。這個是普遍使用的約定，不只是在css文件中，也多出如今書裏和文章裏。許多人認爲他的可讀性很好，這也就是什麼我在本文使用他的緣由。

　　然而在和團隊的工做中，尤爲是大型的css文件，我是將樣式寫成一行:

?
1
.alert {background:#fff;border:1pxsolid#ff0;font-weight:bold;padding:10px;}

　　就我我的和個人團隊而言，以爲單行的可讀性更好。當你查找css時多行樣式就變得很麻煩，相比較而言單行查找更容易。

　　對於你和你的團隊，選擇最合適你的團隊的格式，並一直使用他。

　　須要依照字母順序排列嗎？

　　一些人建議將每一個聲明按照字母表的順序排列，方便快速查找一個屬性。之前我對這樣的事情並不在乎，可是通過處理供應商混亂的css以後，我意識到將一些思想應用到樣式聲明的組織中是個很好的主意。

　　儘管我發現按照字母表排序頗有用，可是我仍是會根據上下文來組織哪些屬性放在一塊兒。好比，我喜歡將全部的盒模型屬性放在一塊兒。若是我使用了絕對定位，我就把這些屬性放在一塊兒:

?
1
2
3
4
5
6
7
8
#logo {    
  border:1pxsolid#000;    
  margin:0;    
  padding:0;    
  position:absolute;    
  top:5px;    
  right:3px; 
}

　　這裏沒有對錯之分，僅僅是決定用哪一種屬性的排序並一直用它就行了。

　　使用簡寫

　　使用css簡寫一直是認爲能夠提升你的css水平的方法。他同時也適用於團隊，它不只能夠有助於瀏覽，並且能夠方便設置你們遵照的標準。這樣就減小了花費在思考和書寫樣式的時間。

　　0值

　　若是你使用0值，沒有必要給他指定單位:

?
1
margin:2px3px0px4px

　　變成

?
1
margin:2px3px04px

　　顏色模式

　　十六進制顏色值若是是由三對數組成，能夠從每組中抽出一個數組成該顏色值的簡寫:

?
1
color:#ff0000

　　寫成

?
1
color:#f00

　　盒模型屬性

　　盒模型中的margin，padding，border若是四邊值相同，能夠合併:

?
1
padding-top:5px;padding-right:5px;padding-bottom:5px;padding-left:5px

　　合併成

?
1
padding:5px

　　若是上下，左右值同樣，你只須要寫兩個就夠了：

?
1
padding:5px10px5px10px

　　合併成

?
1
padding:5px10px

　　字體屬性

　　多條字體屬性能夠合併成一條

?
1
font-style:italic;font-weight:bold;font-size:90%;font-family:Arial,Helvetica,sans-serif;

　　合併成

?
1
font:italicbold90%Arial,Helveticasans-serif

　　背景色屬性

　　背景屬性也是能夠合併的

?
1
background-color:#fff;background-image:url(logo.png);background-repeat:no-repeat;background-position:010%;

　　合半成

?
1
background:#f00url(logo.png)no-repeat010%

　　請注意最後兩個例子，字體和背景屬性。屬性值的聲明順序要按照w3c的標準來。

　　驗證，驗證，再驗證

　　雖然一些人認爲驗證css須要指定一個很好的驗證規則，這一點我不強求可是他絕對是有要求的。驗證可以確保你的工做，是否準備好分享給團隊的其餘成員，因此他應該知足下面要求：

　　1.容易開發和故障排除

　　2.保證如今和將來的瀏覽器顯示一致

　　3.保證頁面的快速加載

　　4.做爲可訪問性的一部分

　　5.把他正確的寫出來

　　我建議使用W3C CSS驗證服務。

　　壓縮工具

　　若是你的團隊關心文件大小，頁面加載和帶寬的話，你應該考慮使用一個壓縮工具。它主要是用來去除沒必要要的註釋，空格。這裏有一些壓縮工具能夠考慮：

　　1.CSS Compressor

　　2.CSS Optimizer

　　3.Code Beautifer

　　4.CSS Tidy

　　我不建議在開發的過程當中壓縮文件，由於壓縮能夠減少你的文件大小，同時也削弱了你和團隊之間協同開發和處理css 的能力。由於他去掉了具備可讀性的全部註釋和空格，因此應該把壓縮做爲產品上線的最後一道工序。

　　冰山一角

　　本文中提到的只是少數基礎實踐，他們能夠幫助你和團隊高效的工做。遵循這些準則能夠進一步完善你的css。若是你很感興趣的話，我推薦你閱讀下面的文章:

　　1.Different Ways to Format CSS

　　2.Unique Pages, Unique CSS Files

　　3.Single-line vs. Multi-line CSS

　　4.CSS Property Order Convention

　　5.On HTTP: Page Load Times, Multiple File Requests and Deferred JavaScript

　　6.Don’t Use @import

　　7.Efficient CSS with shorthand properties

　　8.CSS Sprites: What They Are, Why They’re Cool, and How To Use Them

　　9.Object Oriented CSS

　　遵照黃金定律

　　無論你是工做在一個團隊中，仍是做爲外包或是做爲團隊的惟一成員，這些css準則將爲你往後成爲一個優秀的團隊成員打好堅實的基礎，它不只節約你的開發時間，也避免了沒必要要的沮喪情緒。

　　譯者手語：初次翻譯前端技術博文，整個翻譯依照原文線路進行，並在翻譯過程略加了我的對技術的理解。若是翻譯有不對之處，還煩請同行朋友指點。謝謝！

　　英文原文：http://msdn.microsoft.com/en-us/magazine/ff679957.aspx

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程