这个字面上的技术谈话 (YouTube 视频嵌入其中) 由 Zach Leatherman 发表，非常有趣。 演讲中充满了有趣的技巧，所以我在此记录了一些笔记。

继续阅读 →

我和 Dave 推出了 一个 Patreon 用于 ShopTalk Show。 支持我们，您将获得两件无价之宝。

1. 支持该节目带给你的那种美好感觉，该节目需要编辑、转录、开发和托管等成本。
2. 访问我们仅供支持者使用的 Discord。

我认为 Discord 可能是我们做过的最棒的事情。 如果我在这里引发了 FOMO，我很抱歉，但我要说，这是一个很棒的团队。 我个人的目标是在那里提供帮助，但其他人也都很乐于助人，以至于我实际上学到的东西比我分享的还要多。

继续阅读 →

Google 已经表示 核心 Web 指标 (CWV) 将成为 SEO 因素，而且日期已经不远了：2021 年 5 月。 因此，我看到有些人正在拼命确保这些指标良好。 你知道，字母缩略词汤：CLS、LCP 和 FID。 现在开始出现越来越多的 工具 来测量和诊断问题。 希望，一旦诊断出问题，你就知道该如何解决它们。 例如，如果你有糟糕的 CLS，那是因为你加载了一些（可能是广告）会改变布局的东西，你应该停止这样做，或者提前为它们留出空间，这样布局改变的次数就会减少。

但是 LCP 呢？ 如果你有一个巨大的英雄图片，需要很长时间才能绘制，导致你的 LCP 数字很糟糕怎么办？ Chris Castillo 的技巧 就是在用户以某种方式进行交互之前，根本不加载英雄背景图片。 这看起来很奇怪，但 Chris 做了一些简单的测试，发现有些用户并没有真正注意到。

继续阅读 →

PPK:

在介绍宽度和高度时，我解释说，默认情况下，宽度会占用尽可能多的水平空间，而高度会占用尽可能少的垂直空间。 这会导致对这两个相反模型的讨论，我将在下面摘录。

我的问题是：我应该给这些模型起什么名字？

三个选项

• 内向外 和 外向内
• 基于上下文 和 基于内容
• 外在尺寸 和 内在尺寸

在 这篇文章 中有更多上下文。

我绝对不喜欢内向外和外向内——它们让我的头脑混乱。 我认为我要投票给外在尺寸和内在尺寸。 我最近听到这些术语被提及得很多，而且它们与规范相匹配，这是我喜欢的一点。 同时，我确实觉得基于上下文和基于内容可能更加清晰，但由于它们已经被抽象化和虚构，所以不妨使用已经流行的抽象化和虚构术语。

我喜欢标准从许多开发人员已经做的事情演变而来，并且变得更加容易和防错。 Kitty Giraudel 在 这里 提到了跳过链接，每个网站可能都应该有这样的链接，并且有一整套清单列出了我们可以而且确实会搞砸的事情。

• 它应该是第一个要进行制表键操作的内容。
• 它应该 小心地隐藏，以便它仍然可以获得焦点。
• 当获得焦点时，它应该变得可见。
• 它的内容应该以“跳过”开头，以便易于识别。
• 它应该指向页面的主要内容。

继续阅读 →

在 “究竟是什么，z-index？” 中，Josh Comeau 将 Photoshop 或 Figma 等设计软件中的图层组类比于 CSS 中的 堆叠上下文。 如果你在 Photoshop 中有一个图层组 A 中的元素位于图层组 B 之下，那么你无法做任何事情将 A 的子级推到 B 中的任何东西之上，除非将整个图层组 A 移动到 B 之上，或者去掉分组。

继续阅读 →

AVIF 已经获得了许多科技媒体的关注，但 Jon Sneyers 热衷于 JPEG XL （这很有道理，因为他“是 JPEG 委员会中 JPEG XL 特设小组的主席”）。 根据 Jon 的比较，JPEG XL 在所有方面都名列前茅，除了低保真压缩之外，它还提供渐进渲染，而其他下一代编解码器都没有提供。 但 WebP（不要与即将推出的 WebP2 混淆！）现在已经拥有所有主要浏览器的支持，因此它占据了一定的优势。

继续阅读 →

Alex Russell 对性能及其对移动用户的影响做了一些有趣的笔记。

[…] CPU 的改进速度不足以应对前端工程师对资源的乐观假设。 如果在工具方面有明确的好消息，那么多个流行工具现在都包含了阻止发送第一方 JS 的选项（Next.js、Gatsby），尽管 JS 社区仍然顽固地否认客户端脚本的成本。 希望，这类工具链的进步能够在我们过渡到低脚本排放的世界时，提供一个更容易获得的桥梁。

继续阅读 →

如果你在一个长滚动页面上有一个目录，例如，由于使用了 position: fixed; 或 position: sticky;，那么 JavaScript 中的 IntersectionObserver API 是突出显示目录中对应内容出现在视图中的项目的完美伙伴。

继续阅读 →