Zach Leatherman 概述了一种加载 web 字体的全新方法，该方法可以分成两个阶段

…而不是在第一阶段使用完整的罗马 web 字体，它会加载罗马 web 字体的子集，在这种情况下，只包含大写和小写字母字符。

然后，在第二阶段，我们可以加载该字体的所有其他部分，例如数字或特殊字符。 最终，这极大地缩短了读者看到回退字体和花哨的 web 字体之间的切换时间：第一阶段的大小仅为 9kb，然后被替换为完整的 25kb 版本。

这里的难点在于，许多字体铸造厂不向开发人员提供对子集字体文件的选项。

我认为 Ashley Nolan 的想法是对的

许多关于 PostCSS 的文章将其功能与 Sass 的等效功能进行比较，但 PostCSS 不必用作 Sass 的替代方案。 相反，它可以用于向您的工作流程添加 Sass 不提供的其他功能。 … 这些额外的任务可以在 Sass 编译之前或之后运行，因为 PostCSS 可以解析 SCSS 和 CSS。

PostCSS 已经被证明对于开发人员来说编写插件更容易。 有许多非常引人注目的插件。 但是，我认为，挑选出，比如，十几个试图复制 Sass 已有功能的插件，以及你发现有用的其他插件，是一个错误。 你的 CSS 代码库可能会变成这种奇怪的高度定制的语法 - 你会像在孤岛上编码一样。 更不用说要依赖无数第三方维护人员了。

我认为诀窍是使用 Sass（它在过去几年中拥有许多经过实战检验的强大语法选择），并使用好的插件来加入 PostCSS 处理。 “好”意味着积极维护，并且不会破坏语言。 我更喜欢那些语法看起来很熟悉的插件，但它们是新发明的，因此永远不会与当前的 CSS、未来的 CSS 或其他预处理发生尴尬的冲突。

Una Kravets 在这个来自 dotCSS 的精彩演讲中，带我们了解了混合模式、渐变和 CSS 滤镜。 特别有趣的是，看看其中一些很酷的技巧如何让我们完全绕过设计工具，以便我们可以让浏览器为我们完成所有工作。

她还针对 CSS 图像效果撰写了一个六部分的博客文章系列（复古褪色、3D 眼镜、晕影、散景、宝丽来 以及 红外线）。

FullStory 是一个客户体验平台，它为产品、营销和支持团队提供了前所未有的洞察力，可以了解访问者和客户的互动。 通过向任何网站添加一个简单的脚本，FullStory 可以捕获访问期间的每个事件和互动，从而轻松地回放、搜索和分析每个用户的体验。

FullStory Searchies 可以智能地确定您想对搜索或细分进行哪些提问，并以最直观的视觉方式呈现答案：漏斗图、折线图、条形图等等。 使用 Searchies，FullStory 使您能够轻松地在汇总数据和构成该数据的单个客户之间无缝切换。 免费试用 14 天，获取完整的故事 。

Rebecca Murphey 在 dotJS 2015 的演讲中探讨了围绕 HTTP/2 的各种陷阱。 例如，服务器将如何支持它？ 我们的前端处理将如何改变以最大程度地利用这个新的协议？ 开发人员将如何知道一切都正常运行？

Brad Frost 创建了一个非常有趣的 可视化工具，它可以帮助团队思考性能预算。 它将所有资产（HTML、CSS、JS、图像、字体等）显示为一个比例条形图的一部分。 这是一种很棒的查看方式，因为它强调了“增加一个，其他就必须缩减”的概念。

Nadav Soferman 撰写了一篇关于开发人员尝试使图像响应式时可能犯的常见错误的文章

无论您选择哪种响应式设计解决方案或框架，您仍然需要生成并提供每个图像的多个版本。 对于所有方法和框架来说，找到最合适的解析度（即每个特定图像的响应式断点）的挑战是常见的。

特别让我惊讶的是，为了获得最佳的性能提升，我们需要根据图像本身提供不同数量的缩放图像。 一张图像可能需要五个版本，而另一张图像可能需要九个版本。

Nadav 还带我们了解了一个名为 响应式断点 的新工具，该工具旨在解决许多这些常见错误。 如果我们上传一张图像，该应用程序将允许我们下载缩小的图像，向我们展示哪些是该特定图像的最佳断点，然后会提供一个带有标记的清晰示例，以便我们可以将其直接添加到我们的设计中。

此工具处理图像创建和 srcset 属性创建，但我一直梦想着一个用于 sizes 属性创建的自动化工具。 例如，您打算在其中使用图像的页面将在 iframe 中加载。 iframe 会进行一些大小调整，观察图像宽度发生了什么变化，并记录戏剧性的变化（这很可能是断点）。 然后，它会根据这些信息智能地创建 sizes 属性。 #HotAppIdea。 这也让我想起，在设计发生变化时，在 <meta> 标签中设置大小信息会多么有用。

Alex Russell 关于当前测试实验性 Web 功能的问题

前缀“看起来”很丑陋，人们认为这种丑陋 - 以及 web 开发人员对专有代码的厌恶 - 会导致网站在标准到位且浏览器实现后停止使用它们。 但事实并非如此。

像 Autoprefixer 这样的工具加剧了我们开发人员一有机会就使用带前缀的任何东西的问题。

他谈到了解决这个问题的一些策略，但坦白地说，在我看来它们仍然不完美。 作为一个很小的轶事证据：我更倾向于在它们感觉具有某种持久性之前不使用新功能。 呃，我想这就是问题所在。

在 Web 平台中，缺少的要素是限制实验人群的能力。 如果我们可以确保实验永远不会危及整个 Web，那么实验就可以在固定时间内运行，而无需担心会破坏 Web。 短时间和小的、忠诚的测试人群允许进行更多迭代，这最终应该会导致更好的功能。 Web 开发人员的反馈应该成为标准制定过程中的最重要声音，而只有在 Web 开发人员能够更多地参与功能演变之前，我们才能实现这一点。

“浮动标签” 是一种常见的图案，其中表单的 label 显示在 input 的顶部，直到有人点击它。 然后它会过渡到一旁，露出底部的占位符文本，但 label 仍然会在上方或下方可见。

Emil Björklund 带领我们了解 一个有趣的演示，它复制了这种模式，但不需要任何 JavaScript，并且使用了 :placeholder-shown 伪选择器。

请注意，还有其他仅使用 CSS 的方法可以实现这一点（在 这个大型收藏 中查看大量不同的方法），但 :placeholder-shown 是最适合这种情况的选择器，除了它目前的支持程度。

由 美国总务署 组织的一个项目，该项目概述了联邦机构应该如何实施基本的 Web 安全，详细介绍了为什么政府网站应该始终使用 HTTPS 而不是 HTTP

HTTP 已成为当今生活方式的核心。 HTTP 目前是计算机、平板电脑、智能手机和许多其他设备上使用的应用程序的主要协议。 随着我们对互联网的依赖不断增长，对用户隐私和安全的风险也随之增加。 每个未加密的 HTTP 请求都会泄露有关用户行为的信息，未加密浏览的拦截和跟踪已变得司空见惯。 今天，不存在所谓的非敏感网络流量，公共服务不应依赖网络运营商的仁慈。 只要正确配置，HTTPS 可以提供快速、安全的连接，提供用户对政府 Web 服务的期望的隐私和可靠性水平。