如何編寫輕量級 CSS 框架

Github: https://github.com/nzbin/snack

Demo:  https://nzbin.github.io/snack/

前言

這篇文章我已經醞釀了半年之久，或者說拖沓了這麼久吧。想說的東西很多，卻又無從說起。如今輕量級框架如雨後春筍，層出不窮。我想每個人都應該歸納總結工作中的常見需求，編寫一套適合自己的 CSS 框架。在之前的文章中，我提到了物件導向的 CSS（比如 BEM、OOCSS、SMACSS，詳見 http://vanseodesign.com/css/dry-principles/）。這是一種思想，並不涉及具體的 CSS 問題，主要是類命名的策略！現在仍然有很多人對於前端框架的認識還停留在表面，認為 Bootstrap 是後端人員專用，前端沒必要等等。我不知道這種說法從何而來，我最開始也不喜歡使用框架，或許和很多人的想法一樣，畏懼新知識、害怕難以駕馭、遇到問題的時候無法解決等等。最關鍵的一點是很多人認為框架的樣式是固定的，修改起來太麻煩，還不如自己根據設計圖寫起來方便。

為什麼使用框架

為什麼使用框架？答案顯而易見，效率。除此之外，使用框架或者研究框架的意義還有很多，比如物件導向思想的具體實現。在上一家公司工作的時候，開始的幾個專案我也是用最原始的方法書寫 CSS 。專案之中最讓我頭疼的就是類的命名。我想大多數人都是根據功能去命名，這就造成了很多的冗餘，相同的元件可能寫很多次。簡單舉一個例子，如下圖，個人中心的登入介面。

很多人包括我剛開始的時候可能會選擇下面的類命名及佈局方式，其通用性非常差

然而瞭解 Bootstrap 的人應該一眼就發現上圖就是一個 media 物件，無非一些小細節需要調整一下

為了讓文字與圖片居中對齊，我們可以使用 Bootstrap 的 .media-middle 的輔助類。如果在工作中還要根據需求自定義一些輔助類調整細節，當然這是一個移動端的例子，可以選擇移動端框架相關的 media 物件。

另外，在專案改版的時候，原始的方法的修改更是慘不忍睹，可以說是噩夢，冗長的 CSS 檔案、混亂的功能劃分、類名、色值等等。最後也只能硬著頭皮一點一點修改。那一刻我才體會到框架的意義以及前端工具的重要性。我從工作中總結出，要麼你可以熟練的使用某一個框架，要麼就自己實現一個框架。

前端框架對比

目前市面上前端框架主要分重量級與輕量級。重量級主要有 Bootstrap、Semantic、UIkit、Foundation 等，輕量級有 Pure、Skeleton、Miligram 等。經常關注前端動態的工程師會發現輕量級框架每年都層出不窮。在我上面提到的主流輕量級框架之外還有很多類似的框架。我一直問自己，為什麼要重複造輪子。經過研究，我發現這些輕量級框架其實大多都不能勝任工作需求，而且模仿的痕跡很重，基本上都或多或少的有 Bootstrap 的影子。那麼這些輕量級框架有沒有意義呢？當然有。但是就我個人觀點，選擇輕量級框架反倒不如自己實現一個框架。因為大多輕量級框架就像是工作總結，是根據自己的業務需求實現的。所以大多不具有通用性。

前端框架的對比主要以 Bootstrap、Semantic、UIkit 為主，因為我個人感覺這三個最具有代表性，而且設計風格各有特色。Foundation 也有很多大公司在用，但以我個人觀點，無論是框架的易用性還是設計風格，相比其它幾個框架稍遜一籌。

其中 Bootstrap 和 Semantic 是物件導向的最好體現。

我先說一下 Bootstrap 的優勢，不是設計風格，不是模組，不是特效，而是柵格，響應式柵格。Bootstrap 的柵格在與其它框架對比中佔有絕對優勢，無論是柵格的劃分還是類名的風格都堪稱經典。如果讀者有心看一下 Bootstrap 的 Less 原始檔，就會感受到 Bootstrap 對於響應式柵格的獨具匠心。其實在 Bootstrap 之前也有很多柵格方案，但是給人的感覺就是不夠利索，類名繁瑣不好記。而後來的很多框架，尤其輕量級的框架大多都有 Bootstrap 的影子。

下面我們通過對比幾個框架的柵格和按鈕來看一下類命名的策略。

Bootstrap

Semantic

Foundation

UIkit

Pure

通過上面的對比，大家應該已經發現了這些框架的命名策略的不同。不可否認，Bootstrap 的命名最經典。

之前在網上看到有人討論關於框架的易用性，有人說 Bootstrap 的類名太長，然而通過上面幾個框架的對比，Bootstrap 的類並不繁瑣，而且用前處理器編寫框架時巢狀會比較靈活。

Semantic 的類名最簡潔，通過多個定語的修飾組成一句話，確實很有意思。但是過多的修飾類在編寫框架時會稍顯凌亂，有利有弊，因人而異吧。

Foundation 的柵格應該是最豐富的，策略上類似 Bootstrap，只是對公共屬性進行了拆分，大家也可以看看其中的具體細節。

UIkit 和 Pure 的策略相同，都加了字首以區分其它框架，但是很顯然類名過於冗長了。我在編寫框架時也這樣想過，但是最終放棄了這種方式。

關於 CSS 前處理器

CSS 前處理器早已不是什麼新鮮事，但是真正能夠在工作中運用的人有多少呢？熟練使用前處理器特性的人又有多少呢？

我之前工作的時候也沒有用前處理器，因為不用，所以也意識不到前處理器的好處。主要是覺得麻煩，因為要使用編譯器編譯一下，還不如直接寫 CSS 方便。但是在專案維護的時候就意識到前處理器的好處。後來在幾個專案中嘗試了前處理器，但是對於模組化的寫法不太明確。前處理器作為工具，可以實現模組化編寫 CSS，那麼應該如何劃分模組？另外，前處理器有很多特性，但是大多數人剛開始只用到變數和巢狀，其它的特性幾乎很少用到。我相信在自己動手實現一個輕量級框架的過程中，我們可以對前處理器有一個全面的瞭解。

目前流行的前處理器有 Less，Sass，Stylus 三個，選擇哪個完全是看自己的習慣。我最開始因為 Bootstrap 瞭解的 Less，但是因為習慣選擇了 Sass，其次 Sass 的功能要更全面一些。

無論是工作還是自己寫專案，都要搭建一個專案環境，也就是安裝一系列的 npm 包。相比刀耕火種的開發方式，使用工具開發的前期準備過程稍顯麻煩，然而一旦環境建好，後期的開發將會遊刃有餘。

Miligram 這個輕量級框架在 Github 上有很高人氣，但是說實話，用處並不大。不過這個框架的構建方式非常值得學習。雖然 CSS 對於很多人倆說很簡單，但是真要去寫一個框架，還是非常棘手，這時候就需要借鑑一些優秀的框架。

編寫框架大致會用到的 npm 如下：

其實最主要的就是一個 node-sass，其它的都是輔助 CSS 檔案的生成修改，大家感興趣的話可以去 npm 官網搜尋這些外掛，瞭解具體用法，如有不懂可以給我留言，我就不囉嗦了。

編寫輕量級框架

終於到了本篇文章的重頭戲。

簡單介紹一下，我給自己編寫的框架取名 Snack，原意“零食”，主要表達簡單之意。雖然是輕量級框架，但我並不想拿輕量級做為噱頭，畢竟體量輕意味著某些功能的缺失以及疏漏。這個框架的意義更多的是交流學習，我試圖借鑑其它框架的優秀之處，儘量簡化類名，以及嘗試探索一些更通用的元件。

大多數的輕量級框架只是 CSS 框架，不涉及 JS 部分，主要用於網頁的佈局。我之所以打算自己編寫框架，是因為工作中重複的東西太多，通過框架可以很好的將這些零散元件整合到一起。另一方面，寫個小專案，學點新知識是一件趣事。

編寫框架是去年想做的事情，但因為時間原因，拖了很久。寫框架之初我曾陷入一個誤區，我打算設計一些比較前衛的樣式，立體的按鈕、浮動的皮膚等，比如下圖中的風格。

https://dribbble.com/shots/524593-Soft-Interface-Black

但是在斷斷續續編寫框架的過程中，我逐漸找到了方向，上圖的樣式只是一種皮膚，編寫框架之初不應該把重點放在這上面。當然，好的 UI 設計也是框架成功的一部分。

模組劃分

編寫框架的第一步就是要確定框架應該包含哪些模組。因為是輕量級框架，所以模組肯定沒有重量級框架那麼全面，只有核心的一些元件。通過比較一些輕量級框架以及工作總結，大致常用的模組包括柵格、媒體、按鈕、排版、表單、表格、皮膚以及輔助工具。

在常用的這幾個元件中，需要重點關注的是柵格、表單及皮膚，媒體元件也很重要，但是自由發揮的空間不大，我直接用了 Bootstrap 的媒體元件。

命名策略

首先是類命名的層次與結構。類命名一直是我比較糾結的地方，剛開始工作的時候為了起一個見名知意又簡潔的類名總是抓耳撓腮。我在編寫框架時儘量避免與 Bootstrap 的類名重疊，但也不能完全避免。對比其他框架會發現，這種情況不可避免的會出現，畢竟類名會有一定的規律性以及層次性。在這一點上我比較喜歡 Bootstrap 的風格。下面和 Bootstrap 的表單做一個對比。

Bootstrap 的表單結構及類名

Snack 的表單結構及類名

這個表單結構整體而言還算不錯，只是個別地方需要修改。有一些框架不給 input 等元素起類名，而是給父元素一個類名，個人對這種做法表示疑問，不起類名會降低框架編寫及使用的靈活性。

第二個策略是元件的修飾，比如按鈕及皮膚都存在多個語境（顏色、大小等），在這一點上我編寫框架時做了一些簡化，風格上有些 Semantic 的影子。

關於修飾類的策略是一個仁者見仁智者見智的問題，至於哪種方法更好，還需要在編寫框架的過程中摸索。

柵格系統

演示示例: https://nzbin.github.io/snack/#grid

任何框架必須建立在柵格的基礎上才能靈活佈局。我在前面提到了 Bootstrap 的精華就是柵格系統。柵格系統的編寫需要使用前處理器的迴圈功能，否則就要做無謂的重複勞動了。我遇到過一些輕量級框架是用 Less 編寫的，其柵格系統就沒有用迴圈，這樣的原始碼稍顯唐突，可能是作者對 Less 的迴圈功能不熟，當然 Less 本身的迴圈比較弱，用起來有些彆扭。關於前處理器的迴圈，可以參照我之前翻譯的《CSS 前處理器中的迴圈》，比較詳細地對比了三種流行前處理器的迴圈功能。簡單說一下，Less 沒有迴圈，但可以用遞迴實現，而 Sass 和 Stylus 有真迴圈。

我編寫的柵格系統也是預設 12 列，但是後來發現 12 列的柵格缺少最常用的列寬（比如 10%、20%、30%等），比如下面 CodePen 展示的例子用 12 列柵格是無法完成的，所以我又新增了 10 列柵格，但仍然無法面面俱到，不過已經很靈活了。

See the Pen snack-grid by Zongbin (@nzbin) on CodePen.

柵格的使用和 Bootstrap 是一樣的，除了 12 列柵格外，10 列柵格以及均分柵格都要新增 .cols- 類

這個柵格並沒有響應式，只有一個斷點，小屏手機上的話所有柵格都會單行顯示。一方面，這樣的設計符合大多數輕量級框架的初衷；另一方面，我打算再寫一個針對移動端的框架，畢竟 Web 端和移動端的風格差距較大，按照業務需求分開會更好。不過最近我更改了原始檔，為響應式預留了擴充套件方式。

表單

演示示例: https://nzbin.github.io/snack/#forms

在上面的命名策略中已經展示了 Snack 表單的基本結構，基本表單除了結構之外，樣式上並沒有太多可以討論的地方。在此說一下表單中 checkbox 的結構調整，先看一下 Bootstrap 的 checkbox 結構。

以上兩種結構不能有偏差，稍有偏差樣式就會錯亂，靈活性較差。其次我在想兩種結構能不能整合在一起，增強靈活性。想了很久，找到了方法，Snack 結構如下：

也可以將樣式直接加到 label 標籤上。另外，如果將 input 移到 label 標籤外也是沒有問題的，如下：

這種結構有一個好處，就是可以自定義 input 樣式，詳見下面的 CodePen 的 scss 檔案。radio 的設定和 checkBox 是一樣的。

See the Pen snack-forms by Zongbin (@nzbin) on CodePen.

輔助類

輔助類是一系列類的組合，比如字號大小、顏色值、padding、margin 以及左右浮動等。在一些 Bootstrap 搭建的後臺管理系統中尤為常見，這樣佈局起來就會比較靈活。以下是一個邊框的輔助類。

關於輔助類的詳細內容可以閱讀這篇文章《如何編寫通用的 Helper Class》

盒元件

演示示例: https://nzbin.github.io/snack/#boxes

盒元件是我整個框架中比較滿意的一個模組。之所以要做這個元件主要是覺得 Bootstrap 的 list 元件和 panel 元件可以整合到一起。當然，這樣的做法有利有弊。盒元件在後臺管理系統的佈局中表現的尤為突出。其命名也是多種多樣，比如 panel、widget、portlet、ibox、card等，每個後臺管理系統框架都會對這個元件進行深度開發，可見其在佈局上的重要性。給一個元件起一個合適的類名也很關鍵，想了很久，最後用了 box 的類名，當然一般情況下儘量不要用 box，因為這個類名比較寬泛。下面的 CodePen 模擬了 Bootstrap 的 list 及 panel 元件。

See the Pen snack-boxes by Zongbin (@nzbin) on CodePen.

給框架新增主題是一件有趣的事情。Snack 的預設主題是白色，因為喜歡黑色，最後新增了暗夜主題，編寫主題只需改變元件的顏色。演示文件的頁面用了暗夜主題，點選上方的紅色按鈕可以切換主題。

總結

如果大家問我那個框架更好，我會毫不猶豫的選擇 Bootstrap。在工作中可以根據需求的難易進行框架選擇，如果業務比較重，最好根據 Bootstrap 進行二次開發；反之，可以選擇一些輕量級框架，最好還是根據自己的需求造輪子，如果大家願意選擇或是借鑑我的框架，那會是我的榮幸。

打賞支援我寫出更多好文章，謝謝！