Josh Clark 以“我们的答案机器存在过度自信的问题”开头。也许您已经看到搜索结果（以任何形式）呈现出可怕的错误（或至少是“有争议的”）“答案”的例子。#假新闻。

无论我们以何种形式向用户提供搜索，它都倾向于这种方式。这是我们的首要结果，亲爱的用户！与之互动！我们的算法预测您不会后悔！当然，以这种方式呈现结果是有诱因的。

Josh 提出了一些难题

1. 我们何时应该牺牲速度以换取准确性？
2. 我们如何传达不确定性或模糊性？
3. 我们如何识别敌对信息区域？
4. 我们如何提供答案的上下文？
5. 我们如何适应语音和其他低分辨率界面？

对此我可能要补充一点：我们能否找到使这些事情发生的商业激励？能否通过所有这些，做好一份如此出色的工作，从而吸引用户，赢得他们的信任，并使他们成为良好的客户？我担心快速、过度自信、无上下文的答案在短期内是更好的商业模式。

Ire Aderinokun 使用一些 CSS 选择器来捕获有问题的 HTML 元素，例如那些包含内联样式或缺少/错误属性的元素。

我创建了一个代码库，以便我可以创建一个完整页面演示，展示所有这些选择器的作用。您看到的任何红色都是某种问题。

Belén Albeza，“您可能不需要 CSS 框架”

无论使用框架的原因是什么，框架都可能会在您的项目中引入技术债务。

Jen Simmons，“学习如何使用 CSS 编写布局的好处”

我越使用 CSS Grid，就越确信在它之上添加抽象层没有任何好处。CSS Grid 就是布局框架。直接内置到浏览器中。

Ethan Marcotte，“关于容器查询。”

为什么我们不能根据我们正在设计的模块的可用空间来应用样式，而不是查看视口的形状？

简而言之，这就是容器查询试图解决的脱节。随着我们的设计变得更加模块化和模式驱动，媒体查询的价值已经降低。

Dan Mall，“使用设计系统烹饪”

假设我经营一家食品卡车。我在卡车上有一个小厨房，所以需要谨慎选择我储存的食材。…

事实证明，这也是组织设计系统的非常好的模型。

一个合法的 CSS 技巧 由 Eric Meyer 记录！

因此，CSS 中有polygon()，SVG 中有<polygon></polygon>。它们密切相关，但存在各种奇怪之处。例如，您可以在 CSS 中使用path()更新<path></path>的 d 属性，但您无法对polygon()和<polygon></polygon>执行相同的操作。

继续阅读 →

这确实是一个令人兴奋的消息：构成 W3C 的各个小组已就一套规则达成一致，根据这些规则，我们将能够对网页进行注释、突出显示和发表评论，而无需使用第三方脚本或框架。

Dan Whaley 描述了这可能是一件大事的原因

W3C 标准是迈向未来的关键里程碑，在这个未来，所有页面都可以在无需发布者采取任何行动的情况下支持丰富的对话层——因为此功能可以内置到浏览器本身中，并作为原生功能提供，就像网络搜索一样。共同的愿景是，对话将能够在 Web 上的任何地方，甚至本机应用程序中的文档上进行，并且以联合、基于标准的方式内联而不是折叠在下方。

Lea Verou 撰写了关于 HTML API 的设计以及我们如何为网页设计师编写更好的文档的文章。HTML API 是一个术语，指的是通过 HTML 而不是通过 JavaScript 配置和控制的 JavaScript 库。例如<div data-open-modal="#modal"></div>可能会告诉库此元素负责打开一个模态。除了加载库本身之外，没有其他配置或初始化。

本文我最喜欢的部分是 Lea 面对通常被视为简单的即插即用 JavaScript 库的部分

即使是这段很小的代码片段也需要人们理解对象文字、数组、变量、字符串、如何获取对 DOM 元素的引用、事件、DOM 何时准备就绪等等。对于程序员来说看似微不足道的事情，对于没有 JavaScript 知识的 HTML 作者来说可能是一场艰苦的战斗

通过为用户提供 HTML API，我们可以避免潜在的麻烦。

…请记住，其中许多人不会说任何编程语言，而不仅仅是 JavaScript。不要在您希望他们阅读和理解的文本中谈论模型、视图、控制器或其他软件工程概念。您只会让他们感到困惑，并将其拒之门外。

Lea 创建了一个库集合，这些库具有 HTML API。

Vincent De Oliveira 撰写了一篇史诗般的文章，详细介绍了您可能想知道的关于line-height和vertical-align属性的所有内容。如果您曾经在文本旁边对齐事物时遇到麻烦，或者想知道为什么两种字体看起来如此截然不同，那么这篇文章绝对适合您。

Dan Wilson 记录了变换的一个经典烦恼

button {
  transform: translateY(-150%);
}
button:hover {
  /* will (perhaps unintentionally) override the original translate */
  transform: scale(.8);
}

原生（和 WET）解决方案是再次列出原始变换

button:hover {
  transform: translateY(-150%) scale(.8);
}

Dan 的技巧是改为使用自定义属性。在元素上预先设置所有属性，然后在:hover状态下重新设置它们

:root {
  --tx: 150%;
  --scale: 1;
}
button {
  transform: 
    translateY(var(--tx))
    scale(var(--scale));
}
button:hover {
  --scale: 0.8;
}

级联自定义属性 FTW。

Kevin Vigneault

我不认为页面总长度本身就存在问题。不过，我注意到在许多响应式设计中，内容的有目的分组在大屏幕上很容易发现，但在移动屏幕上内容开始堆叠时会变得混乱。

这可能主要是在“内容”网站上出现的问题，在这些网站上，您将内容压缩到旧的内容管道中。我不介意管道，但我认为 Kevin 在这里做了一些明智的思考。在管道化过程中会发生很多不同的模式，并且可能没有得到足够的考虑。

此网站尤其有罪。一个快速的document.documentElement.offsetHeight测试显示为 14749px，超过凯文指出的有点过分的示例高度的两倍。

Brad Frost

前端设计师…生活在两个世界之间的炼狱中

• 他们了解 UX 原则和最佳实践，但可能不会花费时间进行研究、创建流程和计划场景
• 他们对美学有敏锐的眼光，但可能不会花费时间仔细研究字体搭配、比较调色板或创建插图和图标。
• 他们可以编写 JavaScript，但可能不会花费时间编写应用程序级代码、连接中间件或进行调试。
• 他们了解后端开发的重要性，但可能不会花费时间编写后端逻辑、启动服务器、进行负载测试等。

前端开发人员是意识到的。