（四）一份友好樣式的緣起與歸宿

前陣子寫了篇文章，記錄參加第四屆CSS大會的見聞，裡面有個話題——「我不想寫CSS」，誰曾想，有同行抓住我就問——「我的確不想寫頁面，設計給的視覺稿裡面很多字體大小和顏色，不勝其煩，關於多頁面的樣式，你們是怎麼管理的呢？」

真是前人挖坑，後人栽樹~開個玩笑。

這個問題沒有標準答案，一個公司的不同部門，一個團隊的不同個人，都會有不同看法和做法，所以，本文所述，僅代表我個人的經歷和經驗，試圖給大家一個合理的方向。

緣起

CSS是一門略顯尷尬的編程技術，通過選擇器和屬性的堆砌，就能讓頁面更加整齊和漂亮，你可以什麼都不講究，但是，什麼都不講究顯然不是程序員的脾性，程序員向來追求「美」~所以，這個話題得先從設計說起。

一個項目或者產品，外觀設計到功能設計應該是一體的，樣式主要負責外觀。

外觀是一種基本的審美，每個人都有分辨美醜的能力，就是那種批量生產的建站公司都知道，顏色和風格需要跟站點分類相稱，網頁和網頁之間的風格需要統一，一個logo，一種顏色，就是一款產品甚至一個公司的標誌。

所以，網頁始於設計，那麼從視覺到頁面需要一個怎樣的過程？

審思

有人喜歡先寫結構後寫樣式，有人喜歡同時寫，這看個人習慣，也看嫻熟程度。

但不論怎麼寫，最好都先進行審視：它是什麼風格？產品，活動，介紹，遊戲？

這就決定了頁面是靜態元素居多，還是動態元素居多，是文案居多，還是圖片居多，或者圖文混排。

然後在腦海中對其進行區域和類型劃分：（示例）

頭部：導航和banner，或者logo和banner、slogan等。

中部：介紹、資訊、產品等。

底部：底部導航，或者版權信息、小提示、跳轉鏈接、二維碼等。

粗分之後是細分，這裡的細分是：

1、公用部分——包括背景、邊框、陰影等。

2、同類元素——標題、正文、按鈕、圖片、圖標。

3、是否有交互和不同狀態——展開/收起、彈出層、小動畫、作廢/過期/空/不可用狀態。

這樣就有了規劃樣式的大概思路：Reset——公用樣式——個性化樣式。

這裡是要利用好樣式表的層疊特性，以避免樣式衝突，也避免為了修正錯誤無謂地增加權重。

還有另外一個需要注意的問題，以怎樣的策略進行命名？這個問題，看似頭疼，可以回想一下，我們給它們歸類是按什麼分的呢？——視覺效果，所以，命名時依然如此就好，這樣以來，更可讀，也不會與內容緊密相關，提高了復用性。（某些情況下這樣也會有隱患，暫時不講）

應變

完成了前面的事情，問題大都解決了，但是，隨著頁面越來越多，樣式文件也越來越大，會帶來兩個問題：

• 文件載入速度變慢
• 人工維護成本增高

怎麼辦？分組。

標準有兩種：業務類型、文件類型。

將不同業務的html、css、js、圖片，都進行分拆，只共用全局通用的部分，相互之間不依賴、不影響，減小單個文件大小的同時，使每部分文件更易維護。

這一次的分組，看起來是應需而變，但它又何嘗不是跟「審思」的過程相輔相成？進行了這一步之後，第一步就不單單是根據視覺元素來規劃，還要加上分組情況，比如，屬於哪個功能/業務模塊的，應該放到哪裡，它是屬於之前的某個大的文件，還是需要單獨新建。

封裝

分類完成之後，貌似還是不夠，還可以做點什麼呢？

如果把一個網站比喻成一台機器，它就是由很多部件組成的，同樣一種部件，可能在不同地方反覆出現，可以作為組件被分出來。

比如，我們現在抽離出來的組件有：按鈕、彈窗、圖標、表單、箭頭等。

組件的樣式代碼會被添加到公用代碼文件里，這樣的話，樣式只要寫一次，就可以到處使用。

要特別注意的是，這些組件的命名是跟上下文無關的獨立存在，這樣不會跟任何特定項目產生牽連，還能夠利用作用域進行特異化改造。

組件分離了之後，還有什麼可以分嗎？答案是肯定的。

粒度

為什麼還要分，其實到了這一步，才比較接近那位朋友提的問題，當文件和代碼都已經組織得足夠好，還會為什麼而頭疼呢？

工程師最喜歡的是相同，而設計師喜歡製造不同。

設計師：「這個字體能大一點嗎？」「這幾個字能突出一些嗎？」「這裡能不能加個圓角？"

你：「你就不能統一一下嗎？這麼多種我很難做啊！」

矛盾在哪裡？

工程師有代碼潔癖，想用最簡潔乾淨的代碼，寫出高質量頁面。

設計師有創意慾望，在整齊劃一的基本審美前提之下，還肩負著「特色」使命。

• 都是白色界面，出現一個黃條，肯定就更能吸引眼球，用來放一些「警示/公告」之類；
• 都是黑色字體，中間加個紅色、藍色或者橙色，就會讓人明顯注意特殊字眼；
• 都是文字，有大號、中號和小號，就能增加層次感，也能幫助用戶分出主次。

等等

怎麼辦呢？舉我們組為例：

字體大小，有這麼幾種定義，超小、小號、正常、大號，超大，分別對應：10px、12px、14px、16px、18px。

首先它們牽扯到的屬性很少，或者所要完成的使命很單一。

再者，可以用在你實在不知道該如何命名或者沒必要佔用一個類名的地方，如果把它們劃歸到具體模塊或元素裡面，每次重複書寫，還要多個類名，還要多層嵌套選擇器，就顯得得不償失，因為你只是控制一個很通用的屬性，卻新加了兩個需要維護的地方。

同理：一像素邊框、水平垂直居中、不同字體顏色、清除浮動、flex布局、文字溢出省略等等，都可以抽離單獨的類來解決。

關於這種方法，知乎有個話題專門討論，https://www.zhihu.com/question/22110291 有人反對，有人贊同。

有人說難維護，事實上，你可能寫了就沒改過；

有人說背離了結構和樣式分離，實際上它又恰恰利用了表現和內容分離。

忽略一種方法的優點或者故意放大一種方法的缺點去否定它，就是為了否定而否定，是沒有積極意義的。

我還是搬出那句話，脫離實際的最佳實踐就是耍流氓。在談設計模式的時候我就分享過，只用和不用某一種都是武斷的，應該博採眾長。

根據自身業務的代碼積累、迭代，進行不同粒度的樣式抽離，是非常明智的做法。當然，還可以使用預處理器來進行更加通用和靈活的改進，這裡不多說。

所以，最終的結論是：

從源頭開始規範化，在視覺素材的基礎上進行布局和規劃，根據業務和功能的不同對文件進行分組，針對不同頻次和範圍的規則去劃分粒度，應用合理的命名方法減少聯動影響。

遵循此法，便能寫出一份還不錯的樣式文件吧。

時間空間有限，不能涵蓋所有情況，有問題再具體交流。