CSS 樣式書寫規範

可能不同團隊都有各自的規範,又或者很多人在寫 CSS 的時候還是想到什麼就寫什麼,不存在太多的約束。

我覺得 CSS 代碼規範還是有存在的必要的,尤其是在團隊配合,多人協作下,規範就顯得尤爲重要。

本文的所列是實踐當中得出的一套比較不錯的 CSS 書寫規範,並不希望大家完全採用,而是希望可以結合自己的團隊需要,發展出一套適合自己的 CSS 代碼規範。

也希望可以有更多的建議,共同的完善。本規範也可以在我的 Github 上看到,歡迎留言或者提 PR。

我覺得不同的規範都有各自的長處與缺陷,對待所謂的規範最好的方式不是人云亦云,拿來就用,而是應該結合實際情況及需求,取長補短,取其精華去其糟粕。 

 

編碼設置

採用 UTF-8 編碼,在 CSS 代碼頭部使用:

1
@charset "utf-8";

注意,必須要定義在 CSS 文件所有字符的前面(包括編碼註釋),@charset 纔會生效。

例如,下面的例子都會使得 @charset 失效:

1
2
3
4
5
6
7
8
/* 字符編碼 */
@charset "utf-8";
html,
body {
  height: 100%;
}
 
@charset "utf-8";

  

命名空間規範

  • 佈局:以 g 爲命名空間,例如:.g-wrap 、.g-header、.g-content。

  • 狀態:以 s 爲命名空間,表示動態的、具有交互性質的狀態,例如:.s-current、s-selected。

  • 工具:以 u 爲命名空間,表示不耦合業務邏輯的、可複用的的工具,例如:u-clearfix、u-ellipsis。

  • 組件:以 m 爲命名空間,表示可複用、移植的組件模塊,例如:m-slider、m-dropMenu。

  • 鉤子:以 j 爲命名空間,表示特定給 JavaScript 調用的類名,例如:j-request、j-open。

命名空間思想

沒有選擇 BEM 這種命名過於嚴苛及樣式名過長過醜的規則,採取了一種比較折中的方案。

不建議使用下劃線 _ 進行連接

  • 節省操作,輸入的時候少按一個 shift 鍵

  • 能良好區分 JavaScript 變量命名

字符小寫

定義的選擇器名,屬性及屬性值的書寫皆爲小寫。

 

選擇器

當一個規則包含多個選擇器時,每個選擇器獨佔一行。

、+、~、> 選擇器的兩邊各保留一個空格。

1
2
3
4
.g-header > .g-header-des,
.g-content ~ .g-footer {
     
}

命名短且語義化良好

對於選擇器的命名,儘量簡潔且具有語義化,不應該出現 g-abc 這種語義模糊的命名。

 

規則聲明塊

  • 當規則聲明塊中有多個樣式聲明時,每條樣式獨佔一行。

  • 在規則聲明塊的左大括號 { 前加一個空格。

  • 在樣式屬性的冒號 : 後面加上一個空格,前面不加空格。

  • 在每條樣式後面都以分號 ; 結尾。

  • 規則聲明塊的右大括號 } 獨佔一行。

  • 每個規則聲明間用空行分隔。

  • 所有最外層引號使用單引號 ' 。

  • 當一個屬性有多個屬性值時,以逗號 , 分隔屬性值,每個逗號後添加一個空格,當單個屬性值過長時,每個屬性值獨佔一行。

完整示例如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
.g-footer,
.g-header {
  position: relative;
}
 
.g-content {
  background:
    linear-gradient(135deg, deeppink 25%, transparent 25%) -50px 0,
    linear-gradient(225deg, deeppink 25%, transparent 25%) -50px 0,
    linear-gradient(315deg, deeppink 25%, transparent 25%),
    linear-gradient(45deg, deeppink 25%, transparent 25%);
  }
 
.g-content::before {
  content: '';
}

 

數值與單位

  • 當屬性值或顏色參數爲 0 - 1 之間的數時,省略小數點前的 0 。

    color: rgba(255, 255, 255, 0.5)

    color: rgba(255, 255, 255, .5);

  • 當長度值爲 0 時省略單位。

    margin: 0px auto

    margin: 0 auto

  • 十六進制的顏色屬性值使用小寫和儘量簡寫。

    color: #ffcc00

    color: #fc0

 

樣式屬性順序

單個樣式規則下的屬性在書寫時,應按功能進行分組,並以 Positioning Model > Box Model > Typographic > Visual 的順序書寫,提高代碼的可讀性。

  • 如果包含 content 屬性,應放在最前面;

  • Positioning Model 佈局方式、位置,相關屬性包括:position / top / right / bottom / left / z-index / display / float / ...

  • Box Model 盒模型,相關屬性包括:width / height / padding / margin / border / overflow / ...

  • Typographic 文本排版,相關屬性包括:font / line-height / text-align / word-wrap / ...

  • Visual 視覺外觀,相關屬性包括:color / background / list-style / transform / animation / transition / ...

Positioning 處在第一位,因爲他可以使一個元素脫離正常文本流,並且覆蓋盒模型相關的樣式。盒模型緊跟其後,因爲他決定了一個組件的大小和位置。其他屬性只在組件內部起作用或者不會對前面兩種情況的結果產生影響,所以他們排在後面。

 

合理使用使用引號

在某些樣式中,會出現一些含有空格的關鍵字或者中文關鍵字。

font-family 內使用引號

當字體名字中間有空格,中文名字體及 Unicode 字符編碼表示的中文字體,爲了保證兼容性,都建議在字體兩端添加單引號或者雙引號:

1
2
3
body {
  font-family: 'Microsoft YaHei', '黑體-簡', '\5b8b\4f53';
}

background-p_w_picpath 的 url 內使用引號

如果路徑裏面有空格,舊版 IE 是無法識別的,會導致路徑失效,建議不管是否存在空格,都添加上單引號或者雙引號:

1
2
3
div {
  background-p_w_picpath: url('...');
}

 

避免使用 !important

除去某些極特殊的情況,儘量不要不要使用 !important。

!important 的存在會給後期維護以及多人協作帶來噩夢般的影響。

當存在樣式覆蓋層疊時,如果你發現新定義的一個樣式無法覆蓋一箇舊的樣式,只有加上 !important 才能生效時,是因爲你新定義的選擇器的優先級不夠舊樣式選擇器的優先級高。所以,合理的書寫新樣式選擇器,是完全可以規避一些看似需要使用 !important 的情況的。

 

代碼註釋

單行註釋

星號與內容之間必須保留一個空格。

1
/* 表格隔行變色 */

多行註釋

星號要一列對齊,星號與內容之間必須保留一個空格。

1
2
3
/**
 * Sometimes you need to include optional context for the entire component. Do that up here if it's important enough.
 */

規則聲明塊內註釋

使用 // 註釋,// 後面加上一個空格,註釋獨立一行。

1
2
3
4
.g-footer {
    border: 0;
    // ....
}

文件註釋

文件頂部必須包含文件註釋,用 @name 標識文件說明。星號要一列對齊,星號與內容之間必須保留一個空格,標識符冒號與內容之間必須保留一個空格。

1
2
3
4
5
6
7
/**
 * @name: 文件名或模塊名
 * @description: 文件或模塊描述
 * @author: author-name([email protected])
 *          author-name2([email protected])
 * @update: 2015-04-29 00:02
 */
  • @description爲文件或模塊描述。

  • @update爲可選項,建議每次改動都更新一下。

當該業務項目主要由固定的一個或多個人負責時,需要添加@author標識,一方面是尊重勞動成果,另一方面方便在需要時快速定位責任人。

 

SASS 使用建議

嵌套層級規定

使用 SASS 、 LESS 等預處理器時,建議嵌套層級不超過 3 層。

 

組件/公用類的使用方法

組件/公用類使用 %placeholders 定義,使用 @extend 引用。如:

1
2
3
4
5
6
7
8
%clearfix {
  overflow: auto;
  zoom: 1;
}
 
.g-header {
  @extend %clearfix;
}

組件類的思考

使用 SASS ,經常會預先定義好一些常用公用組件類,譬如清除浮動,水平垂直居中,文字 ellipsis。又或者多個元素具有同樣的樣式,我們希望能夠少寫這部分代碼,公共部分抽離出來只寫一次,達到複用。

但是複用的方式在 SASS 中有多種,那麼是使用單獨使用一個類定義,給需要的標籤添加,還是使用 @include 或者 @extend在定義的類中引入一個 @mixin,或者一個 @function 呢?

基於讓 CSS 更簡潔以及代碼的複用考慮,採用上面的使用 %placeholders 定義,使用 @extend 引用的方案。

  • %placeholders,只是一個佔位符,只要不通過 @extend 調用,編譯後不會產生任何代碼量

  • 使用 @extend 引用,則是因爲每次調用相同的 %placeholders 時,編譯出來相同的 CSS 樣式會進行合併(反之,如果使用 @include 調用定義好的 @mixin,編譯出來相同的 CSS 樣式不會進行合併)

  • 這裏的組件類特指那些不會動態改變的 CSS 樣式,注意與那些可以通過傳參生成不同數值樣式的 @mixin 方法進行區分

 

儘量避免使用標籤名

使用 SASS ,或者說在 CSS 裏也有這種困惑。

假設我們有如下 html 結構:

1
2
3
4
5
6
7
8
<div class="g-content">
    <ul class="g-content-list">
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
    </ul>
</div>

在給最裏層的標籤命名書寫樣式的時候,我們有兩種選擇:

1
2
3
4
5
6
7
.g-content {
  .g-content-list {
    li {
      ...
    }
  }
}

或者是

1
2
3
4
5
6
7
.g-content {
  .g-content-list {
    .item {
      ...
    }
  }
}

也就是,編譯之後生成了下面這兩個,到底使用哪個好呢?

  • .g-content .g-content-list li { }

  • .g-content .g-content-list .item { }

基於 CSS 選擇器的解析規則(從右向左),建議使用上述第二種 .g-content .g-content-list .item { } ,避免使用通用標籤名作爲選擇器的一環可以提高 CSS 匹配性能。

瀏覽器的排版引擎解析 CSS 是基於從右向左(right-to-left)的規則,這麼做是爲了使樣式規則能夠更快地與渲染樹上的節點匹配。 


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章