这是一个令人心碎的标题，来自迈克尔·威廉姆森。但我相信它。这有点像博客现象的放大版，如果你花几周时间写一篇帖子，它可能会比一篇20分钟的随意想法帖子更失败。或者，你对某个开发者在完美时机说的一句随口而出的话可能会导致他们做出的巨大转变，永远改变一个项目的进程。对迈克来说，这是一个3000行代码的副业项目，对世界的影响超过了作为软件开发人员的职业生涯。

继续阅读 →

当我思考前端开发真正是什么和感觉如何时，这正是其核心：围绕大量未知因素进行设计，并将这一概念真正视为网络的优势，而不是我们必须克服的弱点或不幸的事实。

凯西·达顿深入探讨了这一点，并在A List Apart上提供了真实的代码和示例。一个反复出现的主题是内容（当然是一个未知数，因为内容会发生变化）可以并且应该驱动设计决策。甚至有人认为容器查询可能并非它们所吹嘘的那样，因为它们仍然基于父级，而不是内容。

在获得可靠的跨浏览器支持之前，很难确定容器查询是否会取得成功。响应式组件库肯定会改变我们的设计方式，并提高重用和扩展设计的能力。但也许我们始终需要调整这些组件以适应我们的内容。

我们无法像以往那样为这个不断变化的环境设计，但我们可以为内容设计。通过将内容放在首位，并允许该内容适应其周围的任何空间，我们可以创建更强大、更灵活的设计，从而延长我们产品的寿命。 

Netlify 主办的免费活动将于下周（8 月 25 日，星期三）举行：使用 Next.js 进行架构设计。这只是一个简短的半天活动。无需多想。

加入我们参加一个特别的活动，我们将重点介绍在生产环境中使用 Next.js 的业务团队，包括架构深入探讨、最佳实践和挑战。Next.js 是 Jamstack 开发人员增长最快的框架。凭借引人注目的开发者体验和高性能的结果，它已成为交付面向客户的网站和应用程序的新兴选择。

继续阅读 →

你不能只使用 @media (prefers-reduced-data: no-preference)，因为，正如 Kilian Valkhof 所说

[...] 如果不支持（因为浏览器不理解媒体查询），或者如果支持但用户想要保留数据，这将是错误的。

通常 @supports 是 CSS 中用于此的工具，但它不适用于 @media 查询。不过事实证明，有一个解决方案

@media not all and (prefers-reduced-data), (prefers-reduced-data) {
  /* ... */
}

这是一个涉及媒体查询语法和浏览器如何评估这些内容的稍微复杂的逻辑难题。最终能够在一个表达式中处理不支持的情况真是太好了。

布莱恩，你知道选项卡是什么。

我的意思是……你每天都在使用它们，在每个操作系统上。每个人都知道它们存在于每个工具箱中。剩下的就是“只需铺平牛道！”但是当你深入研究时，它比这复杂得多。

布莱恩·卡德尔分享了一些关于将“选项卡”引入 HTML 的进展情况。我们有点认为我们知道它们是什么，但你在处理规范和定义它们时必须非常具体。这很棘手。然后，即使你确定了一个可靠的定义，HTML 中的表达方式也不完全清楚。有很多种选项卡的表达方式，它们都以自己的方式说得通。想象一下标记选项卡，你在顶部将所有选项卡作为一行链接或按钮放置，然后在下方放置一堆面板。他们称之为“目录”样式的标记，它在某种程度上是有逻辑的（“标记看起来像选项卡”）。但它也有一些问题，并且看起来带有标题的节更为实用（“如果你有标题，你可以构建目录，但反之则不行”）。辣味节是一种完全不同的模式。而这仅仅是他们面临的一个问题。

我不羡慕这项工作，但我期待着它的进展，部分原因是编写选项卡是一项棘手的工作。并不难做，但很难做好。我过去曾谈到过我如何在 jQuery 中多次构建选项卡，其中只需单击一行链接上的处理程序即可隐藏或显示下方的一些匹配 div。如果你完全忽略可访问性（例如，如何在选项卡之间导航、焦点管理、ARIA 预期等），则这种方法“有效”。

继续阅读 →

艾哈迈德·沙迪德前几天深入研究了形状“剪裁”。想象一个形状，其中刻出了另一个较小的形状。艾哈迈德以其典型全面的方式很好地阐述了情况——查看使事情复杂化的棘手情况。

继续阅读 →

看起来……有 253 个。我喜欢那个小水⥾喷口。（U+297e）。因为。我喜欢它在一个很棒的域名下是一个相当有用的网站，并且背后有一个小型的商业模式。

让我想起了 Notion 中我喜欢的一个小功能，如果你输入短划线箭头（如 ->），它会变成 →——但很智能——就像它不会在内联代码或代码块中那样。

我们对 Pipedream 进行了表面层面的了解，它看起来确实很酷。它就像Yahoo Pipes曾经是的更现代和花哨的版本。更好的比较可能是Zapier，除了你可以编写代码（如果你愿意）来创建易于构建的云函数，这些函数可以由任何东西触发，从 RSS 到 HTTP 请求到 Slack 消息。我不会说 Pipedream 本身很难学习（尽管我承认我没有深入研究），但它确实包含了复杂性。大量的输入、大量的处理可能性以及大量的输出。你可以说，无限的组合。

前几天我看到了并收藏了Napkin.io，到目前为止（因为它才刚刚推出），它似乎避开了复杂性。

计算工具应该为人类而设计。它们应该让我们更有创造力、更自由、更有灵感。我们相信每个人都应该能够访问计算并充分发挥其潜力。

我们正在制作 Napkin 来改变现状，构建一种新型工具——一种不碍事的工具，让你可以编写代码，并且使用起来很愉悦的工具。

理念

它就像我记忆中 Webtask 的一个更简洁的版本。你编写一个函数……就是这样。它可以在你可以访问的 URL 上使用。

每个函数都有环境变量，因此你可以将 API 密钥放入其中以进行代理，如果需要则进行身份验证，日志用于调试，此外你还可以使用 Node 或 Python 编写。这是一个健康的特性数量，并且还有更多特性即将推出，但它确实感觉像是拥抱简单而不是复杂性。

你是否曾经希望在使用移动浏览器时查看网页的 HTML 源代码，而移动浏览器通常不提供此功能？如果你身边有台桌面电脑，有一些方法，但我的意思是只使用设备本身获取源代码。

Neatnik 的小型查看源代码工具可以解决问题。

继续阅读 →

以下是Kilian Valkhof 关于 CSS 嵌套的文章，它目前尚未在浏览器中可用，但很快就会可用。不过，他在 Sass 或 Less 中的 CSS 嵌套和嵌套之间注意到了一些差异。例如，以下代码

div {
  background: #fff;
  & p {
    color: red;
  }
  border: 1px solid;
}

当 CSS 嵌套推出时，最后一行 border: 1px solid; 将不会像在 Sass 中那样应用于 div。这是因为使用 CSS 嵌套，要应用于该 div 的任何样式都必须在编写任何嵌套样式之前编写。我认为这很有意义，因为我倾向于在我的任何 Sass 代码库中强制执行这种样式（它更容易阅读），但我可以想象人们第一次遇到这种情况时会感到困惑。

CSS 嵌套的一个较小但出于某种原因非常令人兴奋的事情是，正如 Kilian 所指出的，我们将能够像这样嵌套媒体查询

body {
  background: red;
  
  @media (min-width: 40rem) {
    & {
      background: blue;
    }
  }
}

这非常令人兴奋！