前端佈局推動劑 - 間距規範化

我是一個愛折騰設計的前端，一直都在標榜本身的頁面還原是多麼的牛 X 。怎麼作到頁面還原？我有一個最笨可是有效的方法，就是把設計稿直接存成圖片，做爲背景圖而後臨摹着設計稿進行開發。我以爲本身太有才了。像素級還原有沒有？

▲ 爲看清效果有作兩像素偏移

可是 Too Young Too Simple 。這種方式雖然保證了頁面像素級還原，可是每一個間距都得測量，就和針線活兒同樣，大大的增長了時間成本。

而且在網頁這種講求容錯性的地方，即便我在「 Chrome 」瀏覽器下對齊了每個像素，也並不能保證在其它瀏覽器中，網頁的呈現也是如此的完美。頗有可能開發到後期一個頁面上的間距有可能有 2px 、3px 、6px、15px … 各類各樣，這對於代碼管理來講也是一個致命的問題。

講到這裏就不得不提一下設計師和程序員的差異了。對於間距難以維護的問題在設計師的角度實際上是不成立的。設計師並不關心元素和元素之間間距的具體數值，只要它們放在一塊兒視覺平衡，只要美，設計師的設計任務其實就已經完成了。

▲ 設計師和程序員工做時頭部運動軌跡徹底不一樣

「 圖片轉自 galshir.com 」

設計和代碼原本就是來自不一樣次元的語言。代碼關注具體數值和邏輯，設計更關注美感和平衡關係。也正由於這個理念的差異，才誕生了處於設計和開發夾縫中的異類 — 前端。雖然如今的前端有嚴重傾向開發的趨勢，可是並不表明前端在擁抱代碼的同時不能再挽住咱們的設計。在我看來，前端更應該像設計和開發的翻譯官。

1、發散 Or 收斂

處於夾縫中的前端，勢必會有向左仍是向右的問題？每當我在前端有疑問的時候，總能在張老師「 前端大牛張鑫旭 」的博客中找到共鳴。這種前端同時兼顧代碼和設計的思路，不經讓我想起了張老師博客中的文章《 以 20 像素爲基準的 CSS 網頁佈局實踐分享 》。

▲ 以 20 像素爲基準的 CSS 網頁佈局原理

網頁基礎行高都默認設定是 20px ，UI 組件的高度都設定爲 40px 。

這就使得咱們網頁中不管是大模塊之間的間距，仍是小的文字和空間之間的間距；不管是水平的間距仍是垂直的間距，所有都是標準的 5 像素的倍數。從而讓咱們全部的大小模塊的實際高度都是 10 的倍數「 padding-top + line-height * 行數 + padding-bottom 」。

咱們以 20px 爲基準進行佈局和 UI 組件設計，使得咱們的網頁間距標準化了，無形之中會讓咱們頁面的排版更專業。

簡單來講若是設計師按照一切的度量單位都是 5 的倍數這個規範去設計網頁，窄的地方 5px ，通常的 10px ，寬一點 20px 以此類推。那麼前端用工具測量間距的時間就大大節省，甚至到最後前端徹底不用測量，憑肉眼稍微看一下就知道間距是多少。

而對於設計師來講，若是有了固定的間距關係，他們就能夠基於這個規律建立輔助線或者網格，在排版佈局的時候只須要對齊這些網格和輔助線就好，這實際上是能夠減輕設計師部分工做量的。間距收斂了，我以前遇到的代碼管理問題也迎刃而解了。

可是理想很豐滿現實很骨感，由於即便是同一個設計師，在不一樣的項目中設計的間距平衡關係也是不同的。一旦你接手的項目和這個衝突，那這個規範就沒有用武之地了。可是有一個點我以爲是能夠深究的，就是頁面網頁間距規範化以後，咱們前端和設計的效率會有相應的提升。雖然這個收斂的理念看起來和設計的發散思惟是有必定衝突的。

可是設計就必定是發散的嗎？

咱們不妨來看看設計的四個基本原則：

1. 對比「 Contrast 」
   

2. 重複「 Repetition 」

3. 對齊「 Alignment 」

4. 親密性「 Proximity 」

能夠看到設計理念自己是發散的，但規範最終都會落點在一個收斂的結論上。

爲何須要規範這個東西？在我看來它的意義在於傳承和協同工做。做爲一個獨立的藝術大師，你大能夠不須要規範這個東西，隨風放浪愛自由怎樣都行。可是在一個強調敏捷開發的工做環境當中，可能規範會比自由更能體現出它「 1 + 1 > 2 」的價值。

那有沒有什麼現存的解決方案是設計和開發都青睞呢？

2、柵格佈局「 CSS grid 」

對於這個問題，首先跳到我腦子裏的是前端中的柵格佈局。具體的發展史你們能夠自行百度，只要知道這個的出處本來是來自於一個叫柵格化設計「 Grid design 」的設計理念，最後被普遍的應用在網頁設計中。

▲ 柵格佈局原理

這裏我簡單介紹一下這個原理。柵格佈局就是把網頁的寬度分割成若干相同的部分，而後儘量的用代碼實現不一樣列之間的各類組合，一般分紅 12 等分或者 24 等分「 由於 12 和 24 均可以分割成經常使用的 2 列 、3 列 、4 列等經常使用的網頁佈局方式 」。咱們 「 Webnovel 」 的 PC 端採用的就是常規的 12 列柵格佈局。

▲ Webnovel PC 端柵格佈局示意圖

這種柵格化的設計讓咱們整個「 Webnovel 」的 PC 頁面佈局保持了統一，呈現出了咱們應有的專業可信賴感。在設計工具中調出這樣輔助框以後，設計師在佈局網頁的時候只須要將模塊對齊到這些矩形框就好，效率提高了有沒有？

對於前端這邊，柵格佈局已是一個很是成熟的解決方案了。只須要在 CSS 預處理器中稍微調調整一下參數，整個的佈局代碼就生成了。結合以前的設計師給到的 UI 組件，即便沒有設計師，前端也能基於交互稿快速的構建頁面的原型。

一個設計和開發都青睞的前端解決方案，一會兒就實現了「 1 + 1 > 2 」的效果。這對於走敏捷開發的團隊來講是很是值得推薦的。

3、網頁間距規範化

柵格佈局其實只解決了網頁中橫向佈局這一個緯度的問題，對於網頁中耗費前端主要測量時間的一些細枝末節的東西仍是無能爲力。因此我和設計師作了進一步的溝通，但願可以挖掘出咱們項目中其它也能規範化的東西。

▲ 前端中影響佈局的盒狀模型

在開發「 Webnovel 」M 站的時候，我就發現了設計稿裏的間距有着相似的規律，只是這個規律，不是張老師提出的 20px，而是 18px 。和設計師溝通以後，咱們決定將某些接近 9 的倍數但只有 1 兩個像素的差異的間距都統一成 9 的倍數。有了這個統一的規律，那麼天然代碼也就有簡單了。

▲ 基於 9px 的間距基礎代碼

至此元素之間的間距問題，我就能夠直接套用以上的間距代碼了。在構建頁面的時候也無需思考無需測量，直接使用「 固然這個代碼由於基礎參數取得太大，增長了計算的複雜度，可能換成 9px 會更好一點後續會改進 」。

▲ 黃色區域左右間距是 18px，底部間距是 9px

4、行間距規範化

既然初次的嘗試我嚐到了一些甜頭，那麼我天然就想將這種方式再延展一點。由於還有一個間距也是比較棘手的那就是行間距。行間距是屬於文字範疇的間距並不是元素間的間距，可是它又同時影響着元素間的間距。這聽起來有點繞口，舉個例子。

▲ 前端視覺稿轉換對比圖

咱們設計稿「 上圖左側 」裏面文字和下面書封的間距是 14px ，行高和文字大小同樣是 12px 。你們可能有發現文字右邊的字符 Y 實際上是超出了咱們容器行高的。前端爲了容錯處理須要設定這一行文字超出隱藏，但由於字符 Y 的小尾巴超出了高度因此就會被裁掉一個像素。

爲了規避這個問題，我會手動將這個地方的行高調整爲 16px。爲了避免打亂設計的佈局，底部間距天然就須要相應縮減成了 12px「 頂部間距也得作相應調整 」。經過這一整個流程能夠看到，僅僅是一個行間距的問題，前端都須要耗費不小的精力。

可是對於設計師來講，在他們的設計工具的環境中，修改某處文字間距不會對其它相鄰的元素有影響。而前端這邊則須要咱們手動的去計算和修改。固然若是有一個統一間距規範這個問題就能夠很容易規避的。

對於行間距，這裏可能要給設計師科普一下了，一般前端會給全文設定一個默認的行高比值。這裏假定行高的高度爲文字的 1.5倍，天然咱們 12px 的文字行高是 18px 「 12px * 1.5 」，16px 文字行高是24px「 16px * 1.5 」…以次類推。若是設計師也走這樣的規範，那對於前端來講只須要設定好了字號，行高就自然對齊了。大大了減小前端代碼行間距的複雜度。可是得注意的是，某些字體在字號偏大的狀況下，若是行高也是 1.5 倍的話，換行的時候就會顯得間距很大。此時須要給這類的文字單獨再指定行高。

▲ Webnovel M 站標題間距規範

在一開始制定設計規範的時候，設計和前端達成一致，制定出適合當前項目的行間距規範。由於前端直接參與了規範的設定，後期間距的測量工做量就相應的減輕了。

5、迴避奇數

問：在網頁環境中，若是一個寬度爲 5px 的元素要在一個寬度爲 20px 的容器中水平居中，應該怎麼對齊呢？

答：上帝也不知道！

▲ 5px 元素在 20px 容器中的顯示區別

在網頁環境中對於上述問題，百花齊放的瀏覽器和紛繁的終端設備處理機制都是不一樣的。有的偏左，有的偏右，更有甚者一下子偏左一下子偏右，致使頁面抖動或者圖像鋸齒虛邊更有甚者撐亂佈局等一系列問題。而每每前端程序卻須要用代碼去修復它們，這明顯是逆天而行，前端真的太不容易了。

奇數對於瀏覽器的呈現是極其不友好的。這彷佛和計算機語言是一門二進制語言有着千思萬縷的關係。咱們網頁中圖像一樣也是遵循這樣一個規則，無論是 Jpg，Png，仍是 Gif 最後都會轉換成二進制的形式進行存儲和展現。

▲ Jpg 圖片壓縮「 PS 60%壓縮比 」對比圖

能夠看到在同等壓縮比下尺寸爲「 1920 * 800 」的圖片比「 1920 * 799 」的圖片大小居然還要小。由於有損壓縮格式 Jpg 是以 8px 爲基本單位進行計算和呈現的。800px 高的圖片在存儲體積更小的狀況下，顯示的細節可能會比高 799px 的圖片還要好。

寫更少的代碼作更多的事件，這不是咱們程序員一直在追求的嗎？但是設計師只須要在設計網頁的時候稍微注意一下，就能夠幫咱們規避部分棘手的兼容性問題。

6、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

歡迎轉載，但請註明做者、出處和連接。