Jonathan Snook 谈到了一个我经常遇到的令人沮丧的 CSS 情况，即让图像/图标与名称/单词很好地对齐。这正是这条推文背后的动力。我感到欣慰的是，他的解决方案通常与我的相同：相对定位，并使用相对单位调整它，直到看起来正确。

Harry Roberts 谈到将 CSS 选择器视为一系列嵌套逻辑。有时人们很难理解为什么长而过于具体的 CSS 选择器会出现问题。当您将其视为一个疯狂的嵌套 IF (SPECIFIC_CONDITION) { } 块时，可能会让某些人更容易理解。

浏览我们的顶级网络字体，以查找目前网络上 50 种最流行的字体。我们的网络字体灵活易用，无需每月付费。在您的网站上免费试用任何字体 30 天。

Matt Gaunt 分享了 IE 10 和最新的 Chrome 和 Opera 如何支持 document.execCommand('copy'); 及其相关功能，这可以带来一些非常方便的用户体验机会。

will-change 属性背后的概念是停止使用诸如 transform: translateZ(0) 之类的 hack 来告诉浏览器在哪里进行优化，并对其进行标准化。典型的，可以理解的抱怨是这会使 CSS 变得复杂。浏览器不应该足够智能地进行这些优化吗，而不是让我们作者来决定？对此，浏览器表示：启发式地确定这些内容几乎是不可能的。就像响应式图像中的 sizes 属性一样——只需告诉浏览器即可使其更快地利用该信息。浏览器还表示，这不是 CSS 变得更复杂了，而是页面。另一个抱怨是，建议使用根据需要使用 JavaScript 应用和删除 will-change 的方法要求太多。

所有这些热身都是为了链接到 Thierry Koblentz 的文章，他在文章中警告说，will-change 可以创建新的堆叠上下文，这可能是意想不到的，并导致跨浏览器差异。

Jamison Dance

如果您不与他人分享经验，您的有效性将永远无法扩展到您自己的努力之外。如果您在不考虑造成这些伤疤的环境的情况下，将您的战斗伤疤传授给他人，那么相信您的人将错过一些很棒的事情。经验丰富的开发人员面临的挑战是如何传授智慧而不传授教条，但大多数开发人员认为他们的个人经验应该被奉为最佳实践。

Marcy Sutton 的新网站“展示无障碍用户界面”。

我不知道你们是怎么想的，但我确实喜欢庆祝好的方面来平衡所有对坏方面的羞辱。

我关于 CSS 选择器性能的轶事证据是：我从未费心对其进行优化，并且通常完全忽略围绕它的传统“建议”，而且它从未成为问题。

Ben Frain 了解了浏览器人员对此的看法，并且

在这一点上，我高兴地再次得出结论，CSS 选择器对于静态页面很少成为问题。此外，试图猜测哪个选择器性能良好可能是徒劳的。

如果您正在执行非常依赖 DOM 的操作，我认为您知道这一点，并且可以在那时担心它。

通常您确实希望 CSS 阻塞渲染。如果页面先加载而没有 CSS，然后在 CSS 被解析并应用到页面时发生偏移，则页面将以非常尴尬的方式加载。

但是，在某些情况下，您希望延迟加载 CSS——例如，您不介意延迟下载的自定义字体的样式表。或者，如果您正在进行关键 CSS，甚至可以延迟加载您的主要样式表。

Keith Clark 在本文中提供了一种非常简单的方法来实现这一点（没有依赖项）。Scott Jehl 表示，onload 的支持参差不齐。他的小型异步 CSS 加载器可能是获得最佳浏览器支持的最佳方法。

延迟加载 CSS 的另一种方法是将其放在文档底部，就像我们经常对脚本所做的那样。但请记住，在头部执行此操作的优势在于下载会立即触发，因此最终速度会更快一些。我们将脚本放在页脚是因为不仅脚本的下载可能阻塞，而且脚本的执行也会阻塞（双重打击）。我不确定 CSS 是否具有阻塞执行（如果可以这样称呼它），但我认为没有（？）。

Sara Soueidan 传达了关于 SVG 最重要的信息：使用 SVG。