Kelly Sutton 发表了一篇名为 Deletability 的帖子，我整天都在思考它，以及他的想法与编写 CSS 的关系。

通过使用代码，我们看到模块化和可删除性密切相关。 正确模块化的代码很容易删除。

编写可删除的代码就是编写好的代码。

显然，这是一种常见的软件编写方法，尽管我从未在前端方面听说过这个概念。 但是！我认为它应该成为我们在命名类或构建复杂布局时要牢记的目标。 在整天思考了这个想法之后，我认为像“我可以轻松地丢弃这段代码吗？”这样的问题应该成为衡量我们是否在编写良好 CSS 的标准。

继续阅读 →

我觉得所有这些问题都是可以解决的，但最致命的问题是 #3：**它们需要空间才能移动到**。 标签不能消失，并且需要始终可读，因此浮动标签模式**实际上并没有节省任何空间**。 你可以一开始就把标签放在它们漂浮到的地方。 这仍然是一种很酷的效果，但它没有为你带来任何好处，反而可能会让你付出代价。

继续阅读 →

Mark Dalgleish 的这篇文章将成为 2017 年最重要的前端开发文章之一。

它与热门话题“JavaScript 中的 CSS”有关。 Mark 向我们介绍了这实际上不是一个简单且单一的概念，而是一系列概念和实现的连续体。 许多项目都以不同的方式来处理它。 最好的方法可能是那些实际生成真实 CSS 的项目。 这些东西与“内联样式”相去甚远。

普通的 CSS 不会消失，但这些 JS 中的 CSS 想法也不会消失。 它们对于许多项目来说确实有一些实质性的好处。 范围样式可以防止样式错误。 通过关键样式提高性能。 只发送所需的最小样式量。 没有人害怕的样式表，不会变成众所周知的“仅追加”样式表。 更不用说，如果你要在 JavaScript 环境中进行样式设置，那么你就可以获得动态样式的可能性，并将这些样式移植到其他平台等等。

就像我上周做的那样，Laurie Voss 看到了一条关于前端开发复杂性的推文，并做出了回应。

从外部来看，2017 年的前端开发看起来病态地过于复杂。 这是一个公平的看法吗？ 如果是这样，为什么会出现这种情况？

— Pinboard (@Pinboard) 2017 年 5 月 21 日

对 Maciej 的推文的回复很有趣。 它们大致分为两派

1. 较老的/非前端开发者：因为网络很糟糕！
2. 当前的前端开发者：因为糟糕的事情很难！

正如经常发生的那样，两派都是正确的！ 网络是一个充满重新发明轮子以及糟糕 API 的混乱局面。 它也是一场创新风暴。

对网站应该能够做些什么的期望已经发生了巨大变化。 用户期望在网络应用程序中获得快速、类似桌面的响应速度和丰富的呈现效果。 他们还期望这些网络应用程序在移动设备上同样正常运行。 而且他们希望这些应用程序能够基本瞬间加载。

Manton Reece 和 Brent Simmons 刚刚发表了他们对 JSON Feed 的看法，这是一种制作 feed 的新标准，就像一组博客文章一样。 格式本身与 RSS 和 Atom 类似，但由于它使用 JSON，因此更容易阅读，并且对开发人员来说更加熟悉。

对于大多数开发人员来说，JSON 比 XML 更容易阅读和编写。 开发人员可能会对使用 XML 解析器感到厌烦，但解码 JSON 通常只是一行代码。

我们希望，由于 JSON 的轻便性和 JSON Feed 格式的简单性，开发人员会更愿意为开放网络开发。

我最喜欢这个项目的地方是什么？ 规范 真的太容易阅读了。

Ian Devlin 的一个不错发现

当元素本身具有焦点或其任何后代具有焦点时，:focus-within 伪类就会激活。

基于子元素选择父元素是**长期以来梦寐以求的**。 其中最珍贵的是 :has()。 我想知道它是否即将到来。

去年年底，金融时报团队推出了一项重新设计，专门针对网络性能和改善用户体验。 因此，在一篇详细介绍他们发现结果的文章中，James Webb 写了关于这种设计如何影响他们的业务

我们希望将页面加载时间保持在绝对最低限度； 我们的目标是成为出版业中最快的网站。

为了强调更快网站对关键内部利益相关者的重要性，我们必须了解网站速度对用户参与度的真正影响。 幸运的是，我们的分析团队已经开发出一种复杂的内部参与度指标，可以准确预测续订订阅的可能性。

通过一系列粗略的 A/B 测试，我们放慢了网站速度，以观察网站速度与参与度和收入损失之间的相关性。 测试结果表明，每增加一秒的加载速度，我们的参与度分数就会提高 5%。 在订阅和广告库存中，这转化为数百万美元的收入。 因此，速度成为了网站的主要要素。

如果你发现这样的案例研究有用，请查看 WPO Stats。

陈慧晶撰写了一篇关于 CSS 字体历史以及 W3C 如何编写规范和奇怪的 CSS 属性（如 font-effect、font-emphasize 和 font-presentation）的优秀文章。

作为我对排版和 CSS 的持续痴迷的一部分，我一直想知道我们是如何拥有比我们能挥舞的棍子还要多的网络字体的。 我喜欢 W3C 的工作方式，因为它们总是链接到规范的先前版本，一直追溯到第一个草案。

虽然这些信息缺少参与规范的制定和实施的各个个人之间进行的各种讨论和会议的完整情况，但它确实提供了一些关于事物如何发展到现在的线索。

Stuart Frisby 记录了在使用 系统字体堆栈 时不应该使用字体速记

…不要在速记字体声明的开头使用 -apple-system，并进行彻底测试，尤其是在使用像系统字体声明这样的专有内容时。 如果它看起来像供应商前缀并且闻起来像供应商前缀，那么至少有一个浏览器会将其视为供应商前缀。

使用 font-family 代替。

来自 Jake Archibald 的另一篇文章！

这篇文章使用**两个** @font-face 集来设置**相同**的 font-family 名称。 第二个覆盖第一个，但只覆盖它的部分字符，这得益于 unicode-range。

你知道设计师喜欢和号吗？ 这是一种趋势。 Dan Cederholm 曾经指出 Robert Bringhurst 的一些建议

由于和号在显示工作中比普通文本中使用得更多，因此更具创意的版本通常更有用。 几乎没有理由不借用斜体和号来与罗马文本一起使用。

然后 Drew McLellan 展示了如何做到这一点（无需使用 <span>），使用 unicode-range。