我是一个爱折腾设计的前端，一直都在标榜自己的页面还原是多么的牛 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 的插件

「 http://sketchapp.rocks/misc/sketch-workflow-8-point-soft-grids/ 」；

▲ 基于 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

欢迎转载，但请注明作者、出处和链接。