我是一個愛折騰設計的前端，一直都在標榜自己的頁面還原是多麼的牛 X 。怎麼做到頁面還原？我有一個最笨但是有效的方法，就是把設計稿直接存成圖片，作為背景圖然後臨摹著設計稿進行開發。我覺得自己太有才了。畫素級還原有沒有？
▲ 為看清效果有做兩畫素偏移
但是 Too Young Too Simple 。這種方式雖然保證了頁面畫素級還原，但是每個間距都得測量，就和針線活兒一樣，大大的增加了時間成本。
並且在網頁這種講求容錯性的地方，即使我在「 Chrome 」瀏覽器下對齊了每一個畫素，也並不能保證在其它瀏覽器中，網頁的呈現也是如此的完美。很有可能開發到後期一個頁面上的間距有可能有 2px 、3px 、6px、15px … 各種各樣，這對於程式碼管理來說也是一個致命的問題。
講到這裡就不得不提一下設計師和程式設計師的差別了。對於間距難以維護的問題在設計師的角度其實是不成立的。設計師並不關心元素和元素之間間距的具體數值，只要它們放在一起視覺平衡，只要美，設計師的設計任務其實就已經完成了。
▲ 設計師和程式設計師工作時頭部運動軌跡完全不同
「 圖片轉自 galshir.com 」
設計和程式碼本來就是來自不同次元的語言。程式碼關注具體數值和邏輯，設計更關注美感和平衡關係。也正因為這個理念的差別，才誕生了處於設計和開發夾縫中的異類 — 前端。雖然現在的前端有嚴重傾向開發的趨勢，但是並不代表前端在擁抱程式碼的同時不能再挽住我們的設計。在我看來，前端更應該像設計和開發的翻譯官。
一、發散 Or 收斂
處於夾縫中的前端，勢必會有向左還是向右的問題？每當我在前端有疑問的時候，總能在張老師「 前端大牛張鑫旭 」的部落格中找到共鳴。這種前端同時兼顧程式碼和設計的思路，不經讓我想起了張老師部落格中的文章《 以 20 畫素為基準的 CSS 網頁佈局實踐分享 》。
▲ 以 20 畫素為基準的 CSS 網頁佈局原理
網頁基礎行高都預設設定是 20px ，UI 元件的高度都設定為 40px 。
這就使得我們網頁中無論是大模組之間的間距，還是小的文字和空間之間的間距；無論是水平的間距還是垂直的間距，全部都是標準的 5 畫素的倍數。從而讓我們所有的大小模組的實際高度都是 10 的倍數「 padding-top + line-height * 行數 + padding-bottom 」。
我們以 20px 為基準進行佈局和 UI 元件設計，使得我們的網頁間距標準化了，無形之中會讓我們頁面的排版更專業。
簡單來說如果設計師按照一切的度量單位都是 5 的倍數這個規範去設計網頁，窄的地方 5px ，一般的 10px ，寬一點 20px 以此類推。那麼前端用工具測量間距的時間就大大節省，甚至到最後前端完全不用測量，憑肉眼稍微看一下就知道間距是多少。
而對於設計師來說，如果有了固定的間距關係，他們就可以基於這個規律建立輔助線或者網格，在排版佈局的時候只需要對齊這些網格和輔助線就好，這其實是可以減輕設計師部分工作量的。間距收斂了，我之前遇到的程式碼管理問題也迎刃而解了。
但是理想很豐滿現實很骨感，因為即使是同一個設計師，在不同的專案中設計的間距平衡關係也是不一樣的。一旦你接手的專案和這個衝突，那這個規範就沒有用武之地了。但是有一個點我覺得是可以深究的，就是頁面網頁間距規範化之後，我們前端和設計的效率會有相應的提高。雖然這個收斂的理念看起來和設計的發散思維是有一定衝突的。
但是設計就一定是發散的嗎？
我們不妨來看看設計的四個基本原則：
對比「 Contrast 」
重複「 Repetition 」
對齊「 Alignment 」
親密性「 Proximity 」
可以看到設計理念本身是發散的，但規範最終都會落點在一個收斂的結論上。
為什麼需要規範這個東西？在我看來它的意義在於傳承和協同工作。作為一個獨立的藝術大師，你大可以不需要規範這個東西，隨風放浪愛自由怎樣都行。但是在一個強調敏捷開發的工作環境當中，可能規範會比自由更能體現出它「 1 + 1 > 2 」的價值。
那有沒有什麼現存的解決方案是設計和開發都青睞呢？
二、柵格佈局「 CSS grid 」
對於這個問題，首先跳到我腦子裡的是前端中的柵格佈局。具體的發展史大家可以自行百度，只要知道這個的出處原本是來自於一個叫柵格化設計「 Grid design 」的設計理念，最後被廣泛的應用在網頁設計中。
▲ 柵格佈局原理
這裡我簡單介紹一下這個原理。柵格佈局就是把網頁的寬度分割成若干相同的部分，然後儘可能的用程式碼實現不同列之間的各種組合，通常分成 12 等分或者 24 等分「 因為 12 和 24 都可以分割成常用的 2 列 、3 列 、4 列等常用的網頁佈局方式 」。我們 「 Webnovel 」 的 PC 端採用的就是常規的 12 列柵格佈局。
▲ Webnovel PC 端柵格佈局示意圖
這種柵格化的設計讓我們整個「 Webnovel 」的 PC 頁面佈局保持了統一，呈現出了我們應有的專業可信賴感。在設計工具中調出這樣輔助框之後，設計師在佈局網頁的時候只需要將模組對齊到這些矩形框就好，效率提升了有沒有？
對於前端這邊，柵格佈局已經是一個非常成熟的解決方案了。只需要在 CSS 前處理器中稍微調調整一下引數，整個的佈局程式碼就生成了。結合之前的設計師給到的 UI 元件，即使沒有設計師，前端也能基於互動稿快速的構建頁面的原型。
一個設計和開發都青睞的前端解決方案，一下子就實現了「 1 + 1 > 2 」的效果。這對於走敏捷開發的團隊來說是非常值得推薦的。
三、網頁間距規範化
柵格佈局其實只解決了網頁中橫向佈局這一個緯度的問題，對於網頁中耗費前端主要測量時間的一些細枝末節的東西還是無能為力。所以我和設計師做了進一步的溝通，希望能夠挖掘出我們專案中其它也能規範化的東西。
▲ 前端中影響佈局的盒狀模型
在開發「 Webnovel 」M 站的時候，我就發現了設計稿裡的間距有著類似的規律，只是這個規律，不是張老師提出的 20px，而是 18px 。和設計師溝通之後，我們決定將某些接近 9 的倍數但只有 1 兩個畫素的差別的間距都統一成 9 的倍數。有了這個統一的規律，那麼自然程式碼也就有簡單了。
▲ 基於 9px 的間距基礎程式碼
至此元素之間的間距問題，我就可以直接套用以上的間距程式碼了。在構建頁面的時候也無需思考無需測量，直接使用「 當然這個程式碼因為基礎引數取得太大，增加了計算的複雜度，可能換成 9px 會更好一點後續會改進 」。
▲ 黃色區域左右間距是 18px，底部間距是 9px
四、行間距規範化
既然初次的嘗試我嚐到了一些甜頭，那麼我自然就想將這種方式再延展一點。因為還有一個間距也是比較棘手的那就是行間距。行間距是屬於文字範疇的間距並非元素間的間距，但是它又同時影響著元素間的間距。這聽起來有點繞口，舉個例子。
▲ 前端視覺稿轉換對比圖
我們設計稿「 上圖左側 」裡面文字和下面書封的間距是 14px ，行高和文字大小一樣是 12px 。大家可能有發現文字右邊的字元 Y 其實是超出了我們容器行高的。前端為了容錯處理需要設定這一行文字超出隱藏，但因為字元 Y 的小尾巴超出了高度所以就會被裁掉一個畫素。
為了規避這個問題，我會手動將這個地方的行高調整為 16px。為了不打亂設計的佈局，底部間距自然就需要相應縮減成了 12px「 頂部間距也得做相應調整 」。通過這一整個流程可以看到，僅僅是一個行間距的問題，前端都需要耗費不小的精力。
但是對於設計師來說，在他們的設計工具的環境中，修改某處文字間距不會對其它相鄰的元素有影響。而前端這邊則需要我們手動的去計算和修改。當然如果有一個統一間距規範這個問題就可以很容易規避的。
對於行間距，這裡可能要給設計師科普一下了，通常前端會給全文設定一個預設的行高比值。這裡假定行高的高度為文字的 1.5倍，自然我們 12px 的文字行高是 18px 「 12px * 1.5 」，16px 文字行高是24px「 16px * 1.5 」…以次類推。如果設計師也走這樣的規範，那對於前端來說只需要設定好了字號，行高就天然對齊了。大大了減少前端程式碼行間距的複雜度。但是得注意的是，某些字型在字號偏大的情況下，如果行高也是 1.5 倍的話，換行的時候就會顯得間距很大。此時需要給這類的文字單獨再指定行高。
▲ Webnovel M 站標題間距規範
在一開始制定設計規範的時候，設計和前端達成一致，制定出適合當前專案的行間距規範。因為前端直接參與了規範的設定，後期間距的測量工作量就相應的減輕了。
五、迴避奇數
問：在網頁環境中，如果一個寬度為 5px 的元素要在一個寬度為 20px 的容器中水平居中，應該怎麼對齊呢？
答：上帝也不知道！
▲ 5px 元素在 20px 容器中的顯示區別
在網頁環境中對於上述問題，百花齊放的瀏覽器和紛繁的終端裝置處理機制都是不同的。有的偏左，有的偏右，更有甚者一會兒偏左一會兒偏右，導致頁面抖動或者影像鋸齒虛邊更有甚者撐亂佈局等一系列問題。而往往前端程式卻需要用程式碼去修復它們，這明顯是逆天而行，前端真的太不容易了。
奇數對於瀏覽器的呈現是極其不友好的。這似乎和計算機語言是一門二進位制語言有著千思萬縷的關係。我們網頁中影像同樣也是遵循這樣一個規則，不管是 Jpg，Png，還是 Gif 最後都會轉換成二進位制的形式進行儲存和展示。
▲ Jpg 圖片壓縮「 PS 60%壓縮比 」對比圖
可以看到在同等壓縮比下尺寸為「 1920 * 800 」的圖片比「 1920 * 799 」的圖片大小竟然還要小。因為有失真壓縮格式 Jpg 是以 8px 為基本單位進行計算和呈現的。800px 高的圖片在儲存體積更小的情況下，顯示的細節可能會比高 799px 的圖片還要好。
寫更少的程式碼做更多的事件，這不是我們程式設計師一直在追求的嗎？可是設計師只需要在設計網頁的時候稍微注意一下，就可以幫我們規避部分棘手的相容性問題。
六、8 Point Grid
為了更充分的證明規範化給網頁開發流程帶來的優勢，我需要一個更系統的解決方案。綜合上述講到的規範化的點，8 這個數字就像是選招的孩子一樣被我相中。 8 既是 2 的三次方，也是 Jpg 壓縮演算法的基數，大多數瀏覽器預設的字型大小也是 16px「 2 * 8 」，網頁圖示的基礎大小也是 8 的倍數… 這一切看起來是如此的巧合，又是如此的契合。
▲ 圖片轉自Elliot Dahl
有了這個想法之後。我網上搜了一下，還真有以 8 為基數的設計規範：
來自 Bryn Jackson's 的 8 Point Grid
「 https://spec.fm/specifics/8-pt-grid 」 ；
甚至還有基於這個設計規範的Sketch外掛：
Sketch 基於的 8 Point soft grids 的外掛
「 sketchapp.rocks/misc/sketch… 」；
▲ 基於 8px 的 UI 元件尺寸
「 轉自：豆瓣部落格 《 UI 設計中的 8 畫素規則 》」
▲ 運用 8px 規則與不按照 8px 規則排列的對比
「 圖片轉自：豆瓣部落格 《 UI 設計中的 8 畫素規則 》」
想想看如果設計師給到的設計稿，不管是元素間的間距，還是文字的行間距甚至是圖片的尺寸，更或者是所有的度量單位都是 8 的倍數。這個對於前端程式設計師來說是一個多麼驚喜的事情。前面我講的幾個問題迎刃而解，只需要在 CSS 前處理器中簡單的寫幾個迴圈，所有的樣式程式碼就自動生成。前端在構建頁面的時候也無需浪費時間測量。一個將標準化發揮到極致的設計規範，這簡直就是網頁開發中的神器。
在我和設計師探討這個方案的時候，互動還給了我一個更加強大的實踐支撐。Google Adroid 的 UI 視覺規範「 Material Design 」也是向 8 這個倍數靠攏的。空洞的理論一下有了實踐的支撐。所以我強烈的想要把這個方案推薦給我們廣大的設計師。
▲ 基於「 8 Point Grid 」改版之後的M站首頁和框架圖
在此次截稿的上個 M 站迭代中，我們的M站的間距已經引入了「 8 Point Grid 」進行了改版。是不是讓強迫症看起來很爽？
你不是一個人在戰鬥
在我衝動的同時，我也得冷靜的思考這樣一個問題。為什麼「 8 Point Grid 」這樣一個被自己奉為神器的規範沒有像柵格佈局那樣火起來？
這個原因在我看來是規範細粒度的問題。柵格佈局對於設計師的限制僅僅在於橫向佈局這一個方面，對於設計其它部分的影響可以忽略不計。但是「 8 Point Grid 」幾乎涉及到了所有的度量單位。這不僅不適用所有的設計風格，也大大限制了設計師的思維空間。這個規範的細粒度一下就把設計和開發放到了天平的兩端。
但是我並不認為僅僅因為這個原因，規範化就失去了它在網頁專案工程中的重要性。程式設計師拼了命的優化邏輯，精簡流程，好不容易將一個 40kb 的 JS 程式碼壓縮到了 10kb。而設計師稍微優化一下圖片格式，就可以輕鬆將一張圖片壓縮掉好幾十甚至上百 KB。
在一個團隊中，如果太過於執念自己手上的東西，很容易走到瓶頸，也很難從巨集觀的角度發現問題。不妨多和自己的上下游多溝通，說不定就能另外開闢出一條省時省力的道路，畢竟我們不是一個人在戰鬥。
本文作者：ziven27
歡迎轉載，但請註明作者、出處和連結。