保持警惕

不久前，Chrome 因禁用跨源 iframe 的alert()、confirm()和prompt()对话框而导致网络瘫痪。其理由是“当前的用户体验令人困惑，之前曾导致网站误以为消息来自 Chrome 或其他网站”；因此，移除该功能被认为比修复用户体验更可取。

但合法使用也受到了影响。由 Chris Coyier 共同创立的广泛使用的代码共享网站CodePen的用户突然发现，他们无法在项目中使用这些功能，因为 CodePen 会在跨域 iframe 中运行代码，以防范 XSS 攻击。随后其他网站也报告了这一情况，在随后的混乱中，该变更被回滚至 2022 年。

在对Coyier 推文的回复中隐藏着Chrome 团队工程师 Domenic Denicola 的惊人声明：

最好让这些教学网站做好准备，最终将它们从网络平台上完全删除。

等等，什么？

阅读删除线程的意图证实了这确实是 Chrome 的立场：阻止对话框（包括onbeforeunload）是一个错误，并且它们未来的删除是既成事实。

自从我上周在推特上发布了此事后，我的通知标签就变成了一片博斯式的地狱景象，所以我很犹豫要不要写这篇文章。但这个故事有几个方面太重要了，我们不能不谈。这不仅仅是一个关于不受待见的 API 的故事，更是一个关于权力、标准设计以及谁拥有这个平台的故事——这让我对网络的未来感到担忧。

入口

Facebook 的 Dan Abramov指出，这些变化毁掉了许多编程教程。谷歌的 Emily Stark建议他们应该使用<dialog>元素。目前，我们先忽略<dialog>Denicola提出将其从规范中移除的缺陷——或者MDN 建议的针对不支持该元素的浏览器的后备方案alert——而是考虑一下在实际应用中会是什么样子。

通常，当我教人们 Web 开发时，他们会通过构建一个简单的猜数字游戏来开始学习 JavaScript：

function game() {
  let number = Math.ceil(Math.random() * 100);
  let guess = prompt(`Guess a number between 1 and 100`);

  guess = Number(guess);

  while (guess !== number) {
    if (guess < number) {
      guess = prompt(`Too low! Guess again`);
    } else {
      guess = prompt(`Too high! Guess again`);
    }

    guess = Number(guess);
  }

  alert(`That's right! The number was ${number}`);
}

game();

它看上去非常简单，但在几行代码的空间里，学生会接触到许多不熟悉的概念：

• 数据类型（字符串与数字，以及它们之间的转换）
• 函数，包括内置函数和你自己编写的函数
• 循环和 if-else 语句
• 运算符

这门课很受欢迎，甚至预示了未来算法的讨论（即使是最聪明的学生也能很快意识到，通过二分查找就能“赢”）。但这门课很难——很容易就学完一个小时。想象一下，在他们完成这门课之前，他们被要求学习DOM、事件处理和异步编程。教育工作者们倾向于使用阻塞对话框API是有原因的。

如果在制定标准时不将教师视为自己的受众，那么无法理解这些 API 在教育领域如此宝贵的原因就不可避免。说 Web 曾经为开发者提供了更好的入门平台，这虽然是老生常谈（而且只部分准确），但这种怀旧的抱怨背后却有道理：Web 平台的易学性长期以来一直是其成功的关键。我们破坏它，后果自负。

隐藏的信号

Chrome 用来判断某个功能是否可以安全地从网络平台移除的“主要信号”是受影响的页面浏览量。如果某个功能出现在 0.001% 的页面浏览量中，则被视为“小而重要”的使用。（跨域访问量约为0.006alert % ，远高于此阈值；同域访问量则高达 50 倍。）

很容易对那些可以量化的事物过度索引，尤其是在谷歌。但当数据主要来自面向公众的生产网站时，并非所有算作某些功能用途的事物都会出现在数据中。教学就是一个例子。还有其他例子。

例如，我曾多次经历过，在调试过程中，一个合适的地点alert是检验假设的唯一方法。理想情况下，我们都应该拥有设备齐全的设备实验室，无论代码在哪里运行，都能远程检查，无论截止日期多么紧迫。但现实并不总是如此。

即使我的代码按预期工作（有时会发生这种情况），alert如果我正在为自己或我的同事构建某些东西并且我预计错误很少发生，我可能会在添加复杂的错误处理之前进行尝试。

安全研究人员经常用它alert来演示漏洞。（是的，将来他们可以使用一些不那么简洁、不那么显眼的东西，比如console.log，但与此同时，如果多年的文献消失了，它们也会立即过时alert。）

所有这些都是合法用途，但都不会影响决定它们是否重要到需要 Chrome 支持的指标。即使我们只关注生产环境的网站，使用量也不一定与重要性相关，正如Dan Abramov 所指出的那样。

破损

Chrome 团队安全专家 Emily Stark 表示，网络攻击是网络上经常发生的事情。

但如果这是真的，那很大程度上是因为Chrome。长期以来，“不要破坏网络”被认为是标准工作的首要指令。回想一下 #smooshgate 事件：一项添加flatten方法的提案Array.prototype最终变成了一项重大变更，因为 MooTools 的一个老版本（至今仍有少数网站在使用）添加了它自己的不兼容的flatten。令人失望的是，一些开发者认为破坏网络是可以接受的，但 TC39 认真对待其向后兼容性责任，最终将其重命名flatten为flat。谷歌的 Mathias Bynens写道：

事实证明，“不要破坏网络”是HTML、CSS、JavaScript 以及网络上广泛使用的任何其他标准的首要设计原则。

这一次，他们的态度就显得更加傲慢了。

在考虑重大变更时，理性的人可能会对优先级的平衡持有不同意见，但最好清楚地了解“重大变更”的含义。在跨域警报变更之后，我听到的众多轶事中，有一个非常引人注目：

我试图从本地废物管理公司那个超级老派的网站上删除我的定期付款账户。Chrome 92 中的跨域确认 () 功能让我很头疼。我换用了 Firefox 才完成。

如果 Firefox 不再是一个选择，无论是因为资金短缺的 Mozilla 停止了开发，还是因为他们实施了现在标准化的规范变更，情况会怎样？我们讨论的不是《太空大灌篮》网站渲染错误的问题，而是人们无法使用网络上的基本服务的问题。上周的讨论中经常提到的一个暗示是，网站所有者可以简单地重新设计他们的应用程序，不使用阻止对话框，而不管这样做的成本有多高。但许多网站已经不再维护，它们的价值并不会因此而降低。

即使我们接受移除类似 API 就代表进步的前提（而我却不接受），我们也无法将“附带损害是进步的代价”这种态度正常化alert。尽管存在诸多缺陷，但人们普遍认为 Web 是一个稳定的平台，今天所做的投资将经受住时间的考验。如果一个网站被视为本质上瞬时存在的对象，而我们今天普遍依赖的 API 可能会被未来的规范制定者视为不必要的包袱，那么 Web 已经在这个世界上失败了。

如果警报实际上是好的，那会怎样？

我们经常被提醒要使用 Web 内置的表单元素，而不是像<div>往常一样重新创建复选框和按钮。它们不仅比您自己构建的表单元素更易于访问，而且即使您认为默认外观“丑陋”，其视觉一致性也能让您的应用更易于用户导航。

然而，当涉及到对话框时，丑陋的默认设置却被视为一个 bug，而不是一个功能。为什么？正如 Heydon Pickering所说：

在 MVP 中使用 alert()、prompt() 和 confirmed() 是大多数开发者最接近提供无障碍对话框的方式。Chrome 移除它们只是省去了这一步。开发者可以直接构建自己性能不佳、难以访问的对话框。

在过去的糟糕日子里， 的行为alert有些令人讨厌——它会聚焦到相关的标签页，并阻止你离开。多亏了多年的努力，这种情况已经不再存在，我认为alert在很多情况下，它比你自己拼凑起来的任何东西都要好。

跨域 iframe 存在安全问题。我仍然认为，移除 iframe 比改进设计使其来源更清晰更安全。

谁拥有网络？

上周的争议中，一个常见的回应是“用 Firefox”。但这并非解决方案。尽管这项改变是由 Chromium 提出的（移除的意图在与其他浏览器厂商讨论之前就已明确），但 Firefox 最终还是支持了。这足以让某件事成为“标准”——两家厂商支持，而没有任何厂商明确反对。

换句话说：当谈到网络标准时，浏览器拥有绝对的主导权。

每当我质疑某个提案的合理性时，总会有人告诉我，我应该直接参与标准讨论——它们就在 GitHub 上！但是，如果没有影响力，开放就毫无意义，而浏览器拥有这一切影响力。这应该让我们感到奇怪——W3C 的选区优先级明确规定，用户和作者（即开发者）的需求应优先于实现者（即浏览器厂商）的需求，然而高优先级的选区却任由低优先级的选区摆布。（Chrome 开发者辩称，在这种情况下，他们是为了用户的利益行事，但Mike Sherov 的这个帖子有力地证明了，这只是一个遮羞布，掩盖了真正的动机，即技术债务。）

与此同时，我们似乎并没有汲取过去的教训。如果alert说移除 API 是可以接受的，那么我们添加到平台的每个 API，如果未来的网络管理员认为它们有害，也同样可以被移除。考虑到这一点，你可能会认为我们会极其谨慎地扩展平台的覆盖范围；然而，我们却以惊人的速度添加 API，这几乎必然会损害平台未来的稳定性。

鉴于Chrome几乎垄断了浏览器市场，我真心担心这一切对网络的未来意味着什么。一家广告公司不应该对我们所有人的事物拥有如此大的影响。我不知道该如何修正标准流程，使其更能代表网络利益相关者的多样性，但我越来越相信，我们需要找到解决办法。