网站的关于我们怎么做,网站建设及推广培训,淘宝网站代做,网站建设网站需要什么软件我是一个爱折腾设计的前端#xff0c;一直都在标榜自己的页面还原是多么的牛 X 。怎么做到页面还原#xff1f;我有一个最笨但是有效的方法#xff0c;就是把设计稿直接存成图片#xff0c;作为背景图然后临摹着设计稿进行开发。我觉得自己太有才了。像素级还原有没有…我是一个爱折腾设计的前端一直都在标榜自己的页面还原是多么的牛 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 容器中的显示区别在网页环境中对于上述问题百花齐放的浏览器和纷繁的终端设备处理机制都是不同的。有的偏左有的偏右更有甚者一会儿偏左一会儿偏右导致页面抖动或者图像锯齿虚边更有甚者撑乱布局等一系列问题。而往往前端程序却需要用代码去修复它们这明显是逆天而行前端真的太不容易了。奇数对于浏览器的呈现是极其不友好的。这似乎和计算机语言是一门二进制语言有着千思万缕的关系。我们网页中图像同样也是遵循这样一个规则不管是 JpgPng还是 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 Jacksons 的 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欢迎转载但请注明作者、出处和链接。
