Steve Ruiz 将这篇文章称为“设计工具微型用户体验的额外模糊版本”，但我发现它很有趣！如果你在设计工具中选择一堆元素，然后旋转它们，然后稍后选择相同的元素并尝试将它们旋转回原位，你会发现它们已经从原始位置“偏移”了一点。

继续阅读 →

有一个古老的俄罗斯寓言，Okhsv 和 Okhsl 坐在一条划艇上，Okhsv 对 Okhsl 说，“HSL 和 HSV 颜色拾取器在设计应用程序中的已知缺点是什么？”我开玩笑，我开玩笑。但实际上，它们是什么？

继续阅读 →

一个单一用途的网站，由 Alexander Vishnyakov 创建，用于测试将任何特定 HTML 元素放在另一种类型的 HTML 元素内是否有效。有点不错，可以快速参考。

一些组合感觉相当明显：你可以在<input>内放一个<video>吗？不，不行。有些比较棘手：你可以在<h1>内放一个<div>吗？不，不行——这个本周咬了我一口（笨蛋）。有些有点令人困惑，比如<div>是<ol>的无效子元素，但却是<dl>的有效子元素。

我的前端工作流程通常是这样的

1. 处理某个东西。
2. 在自动刷新的浏览器中查看该东西。
3. 看到该东西有错误。
4. 在 DevTools 中检查并更正该东西。
5. 在我的代码编辑器中应用正确的代码。
6. 看到正确的代码在浏览器中自动刷新。

我知道，这并不总是很好。但我敢打赌，你至少偶尔也会做类似的事情。

这就是为什么我被 Chris Heilman 文章的标题所吸引：“如果……你可以使用 Visual Studio Code 作为浏览器开发者工具的编辑器呢？”

这个想法是，VS Code 可以用作 DevTools 的编辑器，我们今天可以通过将其启用为实验性功能，以及 Microsoft Edge 来实现。因此，不，这不像一个黄金时段准备好的通用事物，但请观看 Chris 如何激活该功能，将 VS Code 连接到 DevTools，授予 DevTools 写入文件的权限，然后检查本地 URL 的页面。

现在，我在 DevTools 中所做的更改可以同步回 VS Code，并且我可以直接访问从 DevTools 打开和查看特定文件，以在上下文中查看我的代码。我在 DevTools 中所做的任何更改都会反映回 VS Code 文件，并且我在 VS Code 中所做的任何更改都会在浏览器中实时更新。太棒了。

我不确定这是否会成为 Edge 以外的事物，但这种跨平台工作确实让我感到兴奋。

用于研究的网络浏览器，帮助程序员清晰思考。

使用Bonsai，而不是像“我现在要去使用我的网络浏览器”，你按下Option + Space，它会弹出一个浏览器。它是全屏或一个非常小的浮动在所有内容之上的窗口。你可以将事物视觉化地组织成工作区。我认为它非常适合研究，但也让你以不同的方式思考“网络浏览器”界面可以为你做什么。

继续阅读 →

Ahmad Shadeed在博客中表达了这样的观点，即我们可能不再像过去那样需要过多地依赖position: absolute。首先：堆叠元素。例如，如果你有一堆元素应该全部彼此叠加……

继续阅读 →

一篇优秀的文章，来自 Jean Yang。

我所说的开发者体验是指开发人员与他们的工具端到端、日复一日交互的总和。当然，人们比以往任何时候都更加关注开发人员如何使用和采用工具，并且有整个演讲和小组讨论专门针对所谓的“DX”主题——然而，开发者体验的很大一部分仍然在很大程度上被忽视。随着开发人员花费不到三分之一的时间真正编写代码，开发者体验包括所有其他内容：维护代码、测试、安全问题、处理事件等等。并且开发者体验的许多方面继续被忽视，因为它们很复杂，很混乱，并且没有“银弹”解决方案。

她认为 DX 可能已被普遍过度简化，并且存在具有非常不同 DX 的工具类别。

我的主要发现是，实际上存在两种工具类别——因此，存在两种不同的开发者体验需求：抽象工具（假设我们在真空中编写代码）和复杂性探索工具（假设我们在复杂的环境中工作）。迄今为止，大多数开发者体验都仅专注于前一种抽象类别，在该类别中，理解良好的开发者体验比前者更容易。

让我想起了Shawn 的想法：

现在是时候超越开发者体验中的简单问题，开始解决那些令人不舒服的问题了。

我喜欢Katie Kodes 在这里提出的反驳。我过去曾说过，我认为服务器端语言在“构建组件”方面还没有像 JavaScript 那样出色，但是，这是一个很好的观点。

继续阅读 →

我最喜欢的是那些深入探讨“如何像前端开发人员一样思考”的文章。Michelle Barker 在这篇文章中很好地做到了这一点，而且没有分享一行代码！

我们不能再只为“最佳”内容或浏览条件进行设计和开发。相反，我们必须接受网络固有的灵活性和不可预测性，并构建弹性组件。静态模型无法满足所有场景，因此许多设计决策在构建时都落在了开发人员身上。无论你是否喜欢，如果你是一名 UI 开发人员，你就是一名设计师——即使你并不认为自己是！

前端开发中有很多未知数。比我的小清单长得多。未知大小和长度的内容当然就是其中之一。然后将可能性与每个组件变体结合起来，同时确保良好的可访问性，你就需要完成一项非常艰巨的任务。

Baldur Bjarnason将一些小熊粥带到了单页应用程序（SPA）与多页应用程序（MPA）的讨论中。

单页应用程序可以非常棒。大多数团队都会搞砸它们，因为大多数团队都在功能失调的组织中运作。多页应用程序也可以非常棒，无论是在可以适时适地应用它们的功能强大的组织中，还是在功能失调的组织中，因为它们限制了项目范围。

这两种方法都可能好也可能坏。Baldur 指出，管理层在确保任一结果方面发挥着最大的作用。

另一个事实：有很多项目并没有完全采用这两种方法，而是混合使用。我感觉到了。我也感觉人们强烈希望宣布一个获胜者或有一个简单的清单来决定采用哪种方法，但这不可能发生，因为环境太不稳定，并且有太多因素。技术：它很复杂。

最近一期 Web Rush也深入探讨了所有这些内容。