All code in any code-base should look like a single person typed it, no matter how many people contributed. — idiomatic.js

fecs 是以百度前端代码规范为目标的前端代码风格套件，套件包括 htmlcs、csshint、lesslint 和 jformatter，此外还有社区的相关开源模块 cssbeautify、csscomb、fixmyjs 和 esformatter：

显而易见，fecs 不仅能检查 HTML/CSS/LESS/JavaScript 代码的规范问题，而且还能修复代码的规范问题。

代码检查

fecs-check

代码的检查，目前主要是以百度前端代码规范（JS/CSS/HTML） 的检查为首要目标，同时根据 EFE 的技术规划，为 Less 代码规范 的检查带来了 lesslint。

作为一个前端，不可避免同时与三个语言打交道：JS、CSS 和 HTML。而 HTML，超文本标记语言，是其中可编程性最弱的，一直以来得到的关注都较少。加上浏览器对 HTML 逆天的容错支持，即使是错误百出的文档也可以在浏览器里边表现得中规中矩。这样的背景下，绝大部分被产出的 HTML 代码都存在着各种各样的小问题，比如缺少必要的元信息（meta），比如混乱的 class、id 或属性的取值格式；这些问题或影响页面在不同浏览器下的表现，或增大了页面的开发、维护成本。

因此，选用一个合适的工具对 HTML 代码进行质量控制会是一件很有意义的事情。本文选择了 Bootlint、AriaLinter、htmllint、HTMLHint 及 htmlcs 这五个目前最活跃的相关项目进行对比。除此之外还存在如 tidy、W3C/Mozilla HTML validator 等工具，但它们专注于 HTML 规范，几乎不涉及代码风格上的检查，这里就不做比较。

对比角度将主要包括以下几个方面：

• 使用及配置
• 规则实现及自定义
• 性能
• 亮点

为了后续说明的便利，这里先对语法风格的规则进行简单的分类，第一类包括 attr-value-double-quotes（使用双引号包围属性值）， max-length（限制单行最大长度）， tag-pair（要求需要显式闭合的标签显式闭合）等；第二类包括 script-in-tail（JavaScript 内容要求在页面最后嵌入）, title-required（要求 title 标签）, id-class-ad-disabled（不允许在 id 或 class 的值中出现 ad_，ad-，_ad，-ad 等）等。这两类规则有很明显的区别，第一类偏重于代码格式（遵循与否都不影响最终语义），这里叫它格式规则；对应地，第二类偏重语义，即最终 document 的表现，这里叫它语义规则。一般情况下，前者更适合在语法分析阶段做，而后者更适合在分析完后基于分析结果（AST / document）进行。

原文：Responsive Images in Practice

作者：Eric Portis

译者注：感谢米粽、我佛山人和otakustay为译文提出的宝贵意见。

魔鬼因一切我们享受的东西而惩罚我们。

—阿尔伯特·爱因斯坦

图片已经占了 Web 内容的 62%，而且我们每天都在制造更多。如果所有图片内容都能被好好加以利用那的确很赞。但是对小屏或低分辨率屏来说，其中大部分数据都被浪费了。

为什么？尽管 Web 设计初衷是让所有人能通过任何途径来访问，但直到最近，设备的碎片化才迫使业界全面转向了响应式设计。我们在进行响应式设计时，内容可以优雅且高效地流入任何设备。这说的是除了位图以外的所有内容。位图是固定分辨率的。而且他们的容器——敬爱的 img 和它那孤零零的 src——没有任何适配能力可言。

设计师们面临这样一个苏菲的选择¹：让页面在有些情况下变模糊，还是在所有情况下变慢。大多数人倾向于后者，给所有人发送能适配最大、最高分辨率屏幕的图片。浪费啊。

但是！经过三年的辩论，我们有了一些新的标记来解决响应式图片这个问题：