[译] 感觉 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、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。