[譯] 感覺 4px 基線網格帶來的便利

• 原文地址：The 4px baseline grid — the present
• 原文做者：Ethan Wang
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Mcskiller
• 校對者：Charlo-O，portandbridge

我已經使用 4px 基線網格 2 年多了，而且一直在試着讓個人團隊也使用它。最近我終於克服了個人拖延症並決定在個人第一篇 Medium 文章中討論它。我正在尋求有關此方法的反饋，因此別管那麼多了，請讓我知道大家的想法！

---

問題

文本框邊界老是會在文字上下佔用額外的間距，這真的讓我很頭大。所以，當我使用邊界框來測定間距的時候，就會致使最終間距比你預期的間距更大。文字行高越高，帶來的問題就越明顯。在下面的例子中，咱們經過測量邊界框間距來進行設計。當全部的間距都被設定到 32px 時（卡片一所示），視覺上的垂直間距實際上會大於 32px（卡片二所示），儘管你將它們所有設爲 32px 就是想讓它們的大小是同樣的。

解決方法

因爲這個問題，我使用 4px 基線網格來得到更好的視覺準確度。這是個人方法：

1. 在背景設定一個 4px 網格
2. 對齊全部 UI 元素和 文本基線 到基線網格
3. 使用網格替代文本框邊界去測量垂直間距。具體來講，我測量文本的上方間距時以最接近內容上方高度的網格線爲起點，測量下方間距則以文本基線爲起點
4. 此外，受到 Nathan Curtis 在 Medium 上的文章 設計系統中的間距 的啓發，我爲個人團隊定義了一組間距值

爲了讓全部基線對齊到網格上，這種方法基本上將文本的可視高度（內容頂部到基線的高度）舍入爲 4px 的倍數（以下 GIF 所示）。這也許會帶來 1-2px 的偏差，可是仍然比使用文本框計算間距更加準確。

還有一個例外，在將組件或容器中的圖標或文本垂直居中排列時，我不會去使用基準網格進行佈局，由於在大多數時候開發人員會使用 Flexbox 去居中元素，對於咱們雙方來講，這比使用固定間距都更加方便 😉。

---

理由

平面設計的傳統作法是，用基線網格營造出垂直方向上的節奏感。在我平常的網頁設計工做中，明顯須要這種節奏感才能讓對齊效果更好的案例，我見得很少。

對於我來講，使用 4px 基線網格是一種平衡視覺準確度（用戶方面）和設計效率（設計師方面）的方式。在前面的問題部分中，我談到了使用文本框測量會帶來額外間距。而且最後用戶並不能看見文本框，使用這種方法並不那麼合理，特別是它還可能形成視覺上的不平衡，對用戶也沒有好處。另外一方面，忽略邊界框而後使用基線網格測量能夠帶來更好的視覺準確度。下面是這兩種方法之間的比較。咱們能夠看到，當使用相同的間距值（32px、12px、32px、32px）時，使用基線網格的設計能夠帶來更準確的效果。

有人可能會說，若是使用文本框來測量會帶來更多間距，就拿第一張卡片來講，將第一個間距值從 32px 減小到 28px 或者 24px 就可讓「Seattle」的上邊和左邊間距看起來是相等的。可是這樣一來，設計就變成了一個猜謎遊戲，除非你去數像素點，不然你永遠都沒法肯定。而另外一方面，4px 網格提供了更準確而且可預測的方式來設定間距值大約爲 32px（考慮到 1-2px 的偏差）。

從設計效率層面來講，這樣作看起來會更低效，不過因爲使用網格，設計工具（諸如 Sketch 或 Figma）能夠幫助你讓元素和文字基線與網格對齊，所以對齊和調整間距變得更加簡單。下面是我使用基線網格佈局文本的流程：

或者你能夠選擇不使用網格而後從 內容頂部 開始手動測量（以下 GIF 所示），但這樣你就要不斷縮放查看 像素網格。另外，你的畫板大小可能並非 4px 的倍數。

---

已知問題 —— 設計到開發交接

當開發人員使用自動標註工具（InVision、Zeplin、Figma）檢查設計時，使用基線網格測量的佈局的間距值看起來會很隨意。下面就是使用基線網格進行的設計。數字顯示了你會在自動標註工具中看見的內容。

我在上面簡要地提到了 設計系統中的間距 一文。它討論瞭如何使用 CSS 類表示間距值，這有助於保持設計師和開發人員的統一。不幸的是，由於使用基線網格產生的不一樣間距組合帶來的隨機性，咱們很難用一組 CSS 類來表示間距。

咱們還研究了許多人提到的減輕隨機性問題的流行技術，即便用 ::before 和 ::after CSS 僞元素去「裁剪」邊框（本質上就是設置間距，以進行校訂）。然而，個人代碼小能手男朋友 Chris Caruso 告訴我：

使用 ::before 和 ::after CSS 僞元素帶來的效果並不理想，由於它在不一樣字體、瀏覽器、操做系統甚至不一樣屏幕分辨率下效果都不一樣。配置好一套具體使用環境，又可能致使另外一套環境下的間距出問題。從開發人員的角度來看，這種編程並非一種良好的編碼習慣，由於它使用了負邊距而且給 DOM 添加了額外的元素 —— 這二者均可能會帶來一些咱們不但願出現的反作用。所以，在生產環境中不值得去冒這個險。😑

本地化？

我曾作過本地化研究並查看了咱們的產品支持的 8 種文字系統（拉丁字母、中文漢字、西裏爾字母、天城體字母、希臘字母、韓文字母、假名，以及泰文）。而後我發現不管我使用哪一種測量方法，最終，開發者都是從自動標註工具中獲取邊框的間距而後放入 CSS 中。根據你使用的其餘非拉丁字母，即使行高是相同的，它們的視覺高度也或多或少與拉丁字母有誤差。而且它們的基線也可能有偏移。所以不管你使用哪一種測量方法，本地化操做老是會讓間距發生細微變化。不過以下圖所示，儘管間距發生了微小的變化，可是全部的文本仍是保持在了相對居中的位置。

（我對非拉丁字母文字還不是那麼瞭解，不過我是想再多學點的。若是上述的一些結論有不正確或者能夠改進的地方請告訴我。我只會英文和中文，因此在這裏要感謝幫我把這行文字翻譯成其餘語言的工做夥伴。）

提問？

若是文章若是有什麼寫的不清楚的地方，或者你有任何問題、反饋或者有更好的解決方案，請告訴我！我研究這個內容已經很長時間了，因此我很想聽聽你的想法！若是你想聯繫我請直接發送郵件到 ethanw@microsoft.com！

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。