回想n年前刚写前端的时候，在处理一个'鼠标hover切换背景图会闪'的问题时，将两张背景图合成一张图片，顺利解决问题。这应该是我第一次用到雪碧图的情况。

雪碧图作为背景在切换时不会有因为需要等待下载而产生的闪现

如今，打开一个站点，呈现铺天盖地的图片资源的页面随处可见。而多数站点更会用一套包含几十个风格统一的图标的图标库，加之移动端的占比与日俱增，雪碧图这项技术被运用的就越来越普遍。

原文：https://github.com/blog/2112-delivering-octicons-with-svg

GitHub.com 现在不再使用字体来输出图标了。我们把代码库中所有的 Octicon 替换成了 SVG 版本。虽然这些改动并不那么明显，但你马上就能体会到 SVG 图标的优点。

Octicon 上的对比

切换到 SVG 以后，图标会作为图片渲染而非文字，这使其在任何分辨率下都能很好地在各种像素值下显示。可以比较一下左侧放大后的字体版本和右侧清晰的 SVG 版本。

为何使用 SVG？

图标字体渲染问题

图标字体从来只是一种 hack。我们之前使用一个自定义字体，并将图标作为 Unicode 符号。这样图标字体就可以通过打包后的 CSS 来引入。只要简单地在任意元素上添加一个 class，图标就可以显示出来。然后我们只使用 CSS 就能即时改变图标的尺寸和颜色了。

不幸的是，虽然这些图标是矢量图形，但在 1x 显示屏下的渲染效果并不理想。在基于 WebKit 的浏览器下，图标可能会在某些窗口宽度下变得模糊。因为此时图标是作为文本输出的，本来用于提高文本可读性的次像素渲染技术反而使图标看起来糟糕许多。

对页面渲染的改进

因为我们直接将 SVG 注入 HTML，所以不再会出现图标字体下载、缓存、渲染过程中出现的样式闪动（这也是我们选择这种方式更主要的原因）。

页面闪动

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。

最近因为遇到一个float相关的bug，又跑去撸了一遍css标准。然后发现，它确实比其他属性复杂好多，既不像inline-block那样单纯的完成并排显示，又不像绝对定位那样彻底的脱离文档流而不影响别的元素。它唯一单纯的就是，真的是唯一可以实现文字环绕显示的属性。

但是唯一单纯的特点却并不是很招人待见，相反，大家更习惯使用float去完成其他的功能，比如横排展示和自适应分栏布局。

很多人这样用着，只是因为一堆现成的文章告诉他们可以这样用，但是到底为什么可以，以及用的时候要注意什么问题却并不是所有人都知道，结果就是，一时的“便利”，为日后的维护埋了一堆的坑。

这篇文章打算通过将目前一些成文的浮动元素的特点与CSS规范中的具体描述对应，来加深大家对float属性原理的理解。并在后面通过一个bug实例，说明使用这个属性时要注意的问题。

浮动元素的业界公认特点

float属性被设置为非none的元素：

1. 元素被视作块级元素，相当于display设置为"block"；
2. 元素具备包裹性，会根据它所包含的元素实现宽度、高度自适应；
3. 浮动元素前后的块级兄弟元素忽视浮动元素的而占据它的位置，并且元素会处在浮动元素的下层（并且无法通过z-index属性改变他们的层叠位置），但它的内部文字和其他行内元素都会环绕浮动元素；
4. 浮动元素前后的行内元素环绕浮动元素排列；
5. 浮动元素之前的元素如果也是浮动元素，且方向相同，它会紧跟在它们后面；父元素宽度不够，换行展示；
6. 浮动元素之间的水平间距不会重叠；
7. 当包含元素中只有浮动元素时，包含元素将会高度塌陷；
8. 浮动元素的父元素的非浮动兄弟元素，忽视浮动元素存在，覆盖浮动元素；
9. 浮动元素的父元素的浮动兄弟元素，会跟随浮动元素布局，仿佛处在同一父元素中。

目前实现的很多应用都是直接对应上述特点实现的。但是很多人在看过这些描述以后，并不知道它的结论从何而来，无据可循，怎会安心？为了解决大家的疑虑，下面我会将上面的九条与CSS规范做一一的对应。

关于代码静态质量检查，在大佛的上一篇文章 《JavaScript 代码静态质量检查》中已经说得很明白了，虽然主要讲的是 JavaScript 方面，但代码静态质量检查的本质是不变的，今天我们来介绍一下 CSS 方面的静态质量检查。

CSS 中也有一些 Lint 工具，例如 CSSLint，PrettyCSS，recess，CKStyle，stylelint，当然还有百度 EFE 出品的 CSS 代码风格检查工具 CSSHint。本文将从功能、性能、适用范围、规则实现、个性化几个方面对这几个 Lint 工具进行对比。

本文翻译自Ariya Hidayat的Hardware Accelerated CSS: The Nice vs The Naughty。感谢Kyle He帮助校对。

每个人都痴迷于60桢每秒的顺滑动画。为了实现这个顺滑体验现在用的最流行的一个做法就是使用『CSS硬件加速』。在一些极端例子中，强制使用translate3d意味着大大提高应用程序的性能。

现代浏览器大都可以利用GPU来加速页面渲染。在GPU的众多特性之中，它可以存储一定数量的纹理（一个矩形的像素点集合）并且高效地操作这些纹理（比如进行特定的移动、缩放和旋转操作）。这些特性在实现一个流畅的动画时特别有用。浏览器不会在动画的每一帧都绘制一次，而是生成DOM元素的快照，并作为GPU纹理（也被叫做层）存储起来。之后浏览器只需要告诉GPU去转换指定的纹理来实现DOM元素的动画效果。这就叫做GPU合成，也经常被称作『硬件加速』。

不幸的是，浏览器是一个很复杂的软件（Firefox有几百万行代码）。因此一句简单的『使用translate3d来提高性能』并不能囊括所有的情况。如果碰巧有效那不过是瞎猫碰上死耗子而已。所以有必要知道更多的运行机制，才能更好地处理实际情况。