对 Safari 对网络影响的批判

最近有很多关于“Safari 是新的 IE”的讨论（1、2、3、4、5）。我不想重述它的基础知识，但我看到了一些有趣的反驳，最常见的是：Safari 实际上是在保护网络，通过抵制添加造成安全/隐私/膨胀问题的不必要和实验性功能。更具体地说，Safari 的方法并没有保护网络免受臃肿和邪恶的谷歌影响，因为： Safari 没有实现的大多数功能都没有任何安全、隐私或性能问题的迹象，而且它们已经在所有其他浏览器中实现了.最大的 Safari 抱怨与 Chrome 团队的实验性功能无关：它是已实现功能中令人瞩目的错误，由于 Safari 的缓慢发布周期而变得更糟。拒绝参与针对实际用例的有争议的 API 提案实际上并不能保护网络——它只会将网络开发人员和用户推入 Chromium 的怀抱。稍后我们将更详细地探讨这些要点中的每一个，然后我们将讨论 Safari 可以做什么。

也有人提出了其他论点，包括关于 Safari 为什么会扼杀网络的许多猜测——这是为了保护 Apple 的应用商店利润吗？我将完全忽略这些建议，并坚持解决具体问题。他们的理由是他们自己的，在苹果之外我们只能猜测，具体问题可以不加猜测。在我们开始之前，我确实想承认 Safari/WebKit 团队正在努力工作，我非常希望他们成功！ Chromium 的统治对每个人都不利，而构建一个专注于隐私和安全的流行浏览器，正如他们似乎正在努力做的那样，是一个了不起的目标。这并不意味着他们目前的做法值得我们盲目支持。我确信 Safari 团队已经在处理以下问题，而且我认为这些问题很可能从根本上源于关于公司优先级的管理决策，而不是团队本身。不幸的是，今天有大问题，目前的发展轨迹正在使网络变得更糟，而不是更好。在上述三点中，我认为最后一点将是最有趣和最有争议的，但让我们先弄清楚前两点： 一个常见的论点是 Safari 也没有实现所有功能：这不是真的。以下是所有其他浏览器已实现但 Safari 未实现的一些功能的快速列表，没有任何隐私、安全或电池寿命问题的建议：CSS 的包含属性，它将元素的布局与 DOM 的其余部分隔离，改进浏览器渲染性能，并通过隔离为开发人员简化页面布局。 2016 年在 Chrome 中实现，2019 年在 Firefox 中实现。

CSS 的 offset-path 属性，它允许元素沿着 SVG 路径以声明方式进行动画处理。 2015 年由 Chrome 实现，2020 年由 Firefox 实现。 CSS 的 overflow-anchor 属性，可在用户阅读时阻止页面跳转。 2017 年在 Chrome 中实现，2019 年在 Firefox 中实现。 分辨率媒体查询，允许设置内容样式以匹配设备像素密度。 2012 年在 Firefox 和 2013 年在 Chrome 中实现。:focus-visible，通过仅在键盘导航期间显示焦点样式来避免可访问性/设计冲突。 2020 年在 Chrome 中实现，2021 年 1 月在 Firefox 中实现。 TouchEvents，支持网络上的多点触摸和触摸手势。 2012 年在 Chrome 中实现，2017 年在 Firefox 中实现。BroadcastChannel，它允许同一来源的页面轻松通信，例如将所有页面一起注销。 2015 年在 Firefox 和 2016 年在 Chrome 中实现。 beforeprint 和 afterprint JavaScript 事件，允许页面动态自定义打印布局，超越简单的媒体样式。 2001 年在 IE 6 (!!!)、2011 年的 Firefox 和 2018 年的 Chrome 中实现。

scrollIntoView({ behavior: 'smooth' }) 滚动到页面上的一个项目。 2015 年在 Firefox 和 2017 年在 Chrome 中实现。屏幕方向 JavaScript API，允许页面动态处理屏幕方向变化。 2014 年在 Chrome 中实现，2016 年在 Firefox 中实现。AV1 视频和 AVID 图像，一种新的高效且免费许可的压缩格式。 2018 年在 Chrome 中实现，2019 年在 Firefox 中实现。每一个都有一个已发布的标准，并由多个浏览器引擎实现，包括 Firefox，我在任何地方都看不到任何问题。 Safari 团队对我所看到的任何这些都没有明确的公开反对意见，只有沉默。据我所知，Safari 团队也没有任何迹象表明这些功能很快就会出现，而且我已经省略了很多已实现但在标志后面（通常是多年）的缺失功能，但是大概很快就会上线。根据 Can I Use 的指标，Safari 在功能支持方面落后 Firefox 约 10%，落后 Chrome 15%。这包括所有基本功能，如 HTML 图像、表单和链接 - 因此它严重低估了现代功能集。同时，Web 平台测试仪表板（不隶属于任何供应商，有来自 Mozilla、Google、Apple 和整个行业的贡献者）对此有自己的衡量标准，即浏览器对其 Web 开发人员最常用的核心 Web 功能列表的支持计数。 Safari 表现不佳：

“他们只忽略坏功能”的论点因 Safari 以前的行为而变得更弱，因为它缺少这些功能，其中许多功能最终已在没有反对的情况下实现，但比其他浏览器落后多年。如果对这些功能有很好的争论，它们显然应该永远不会被实现。没有很好的案例来实现 web 平台功能，但只是在其他人之后很多年，例如： 日期和时间输入类型 - 在 Firefox 之后 4 年和 Chrome Service Workers 之后 9 年发布，用于页面请求中间件（离线支持和缓存） -在其他地方支持它 2 年后发布 AbortController，中止获取请求和其他异步操作 - 在其他地方支持 IntersectionObserver 一年后发布，以检测元素可见性，例如允许延迟加载 - 在所有地方支持后 2 年发布else 表单验证 - 技术上在 Firefox 和 Chrome 之前发布，但已损坏 7 年无法使用

像这样的例子还有数百个，其中的功能在所有其他主要浏览器中都得到了讨论、实现和标准化，但在此后的几年里却没有在 Safari 中进行讨论。这增加了在现实世界中轻松使用每个浏览器提供的其他标准化功能的延迟一两年（在标准化和实施的现有时间之上），如果它曾经被实施的话。再说一遍：这些不是仅由 Chrome 提供的有争议的功能，它们是得到广泛支持且没有明确反对意见的功能，但 Safari 直到几年后才推出它们。它们也不是在任何意义上“使网络膨胀”的闪亮无关功能：我上面包含的每个示例主要是改进核心网页用户体验和性能。 Safari 在这里放慢了进度。忽略这样的标准并不能帮助网络更加谨慎地发展——一旦这些功能在所有其他浏览器中稳定多年，它们无论如何都无法改变。改进 API 的更好方法是在 Safari 中尽早发布这些功能，在标志和原始试验之后，并在它们稳定之前从尽可能广泛的开发人员和浏览器实现者那里收集反馈，以便反馈可以帮助每个浏览器包括更好的 API。相反，每当 Safari 不支持其他广泛可用的 Web 功能时，开发人员就不能 100% 依赖它们，因此有些人会拒绝使用它们（尤其是在移动用例中）或修改变通方法，因此明确的反馈减少，问题更难发现，开发好的 Web API 对每个人来说都变得更加困难。我将避免猜测所有这些的原因，但很明显这是一个新的发展。在过去（2010 年代初期），Apple 经常在新功能方面处于领先地位，作为第一个发布主要 JavaScript API（如 Web Workers）的浏览器，以及驱动实验性前缀功能（如 CSS Canvas 背景）的浏览器。现在看到主要由 Apple 驱动的网络功能非常罕见。有些东西已经改变了。除了缺少的功能外，Safari 在其实现的各种 Web 标准的功能中还有很多错误。其中许多错误会产生严重影响，否则正常工作的网页会完全失败或布局严重损坏等。以下是最新稳定版 Safari 中存在的当前错误示例：LocalStorage 在更多页面打开时被破坏不止一个选项卡，在大多数用例中可能会导致重大数据丢失：https://bugs.webkit.org/show_bug.cgi?id=225344

13 年前，非输入元素的焦点事件在 Safari 中的行为与其他所有浏览器不同：https://bugs.webkit.org/show_bug.cgi?id=22261 从 HTTPS 访问时，Safari 不正确地将本地主机作为混合内容阻止页面（但允许它来自 HTTP！），打破从 Spotify 到以太坊的用例：https://bugs.webkit.org/show_bug.cgi?id=171934 100vh（100% 视口高度）在移动 Safari 中意味着不同的事情其他地方：https://bugs.webkit.org/show_bug.cgi?id=141832 Fetch 请求流的实现刚好足以通过功能检测，但它实际上不起作用：https://twitter.com/jaffathecake/ status/1420306878580547586 Mousemove 事件在按下修饰键时触发，即使鼠标没有移动：https://twitter.com/jaffathecake/status/1420315350009356293 在许多情况下将元素附加到 shadow DOM 会导致浏览器进程硬崩溃，使包括 redhat.com 在内的网站完全无法访问：https://bugs.webkit.org/show_bug.cgi?id=22 4408 还有很多很多。从轶事到数据：下图计算了整个套件中仅在一个浏览器中失败的 Web 平台测试的数量。黄线是 Safari，多年来在测试中失败的次数明显多于 Firefox 和 Chrome：

对于上面的每个错误和该图中的所有数据，正确使用标准 API 的页面 - Firefox 和 Chrome 完全支持的页面（在 localStorage 情况下，由 IE8 支持！） - 对于所有 Safari 用户来说都是损坏的。这是不好的。 Safari 发布速度极慢，这让情况变得更糟。以下是今天的浏览器发布周期：Edge：每 6 周一次，计划在 2021 年第三季度改为每 4 周一次，提供 8 周稳定的企业选项（这仅适用于稳定的错误修复和功能发布 - 浏览器也每晚发布一次/测试版/预览版以及针对此时间表之外的关键安全问题的紧急补丁）这使整个问题变得更糟，因为即使错误被迅速识别并修复，它们也将至少存在 6 个月，而且可能会很好超越（因为更新是手动的并且与操作系统更新相关联，而不是自动、后台和低麻烦）。这意味着即使在最好的情况下，各地的 Web 开发人员和 JS 库作者也必须为每个 Safari 问题添加永久的解决方法，并支持这些解决方法至少一年，而不是快速修复以解决可能只存在于 Firefox 的错误4周多一点。 Dave Rupert 本周写了一篇很棒的文章，列出了他让 Safari 像其他现代浏览器一样运行所需的特定变通方法。这是艰苦的工作。例如：上面的 localStorage 错误严重破坏了核心 Web API，并且很快得到了修复（在 24 小时内！太棒了）但是在将近 3 个月后的今天，该修复程序仍未发布给用户，所有 Safari 团队可以说是：

我们知道这个错误有多么重要。我们对未来版本没有评论。- https://bugs.webkit.org/show_bug.cgi?id=225344 现在，每个想要在本地存储中存储任何数据的网站都必须接受不可预测的不必要数据丢失，并且这种情况很可能会持续数月。通过使用 IndexedDB 来解决这个问题是有可能的，但是它本身也被上面的另一个错误破坏了。这种缓慢的发布周期也削弱了 Safari 通过频繁的迭代发布获取反馈、推送修复和测试实验的能力。过去 10 年软件开发的一个关键变化是朝着更小和更多增量发布的方向发展，而不是偶尔的大爆炸部署。尽快将软件交到用户手中，并建立一个管道来获取结果反馈，进行更改并部署修复程序，并快速再次发布新版本，这是非常有价值的。看到 Safari 完全避免迭代发布的好处是一种耻辱，它使这里的其他问题变得更糟。我们已经讨论了 Safari 不支持的没有争议的标准 API。让我们来谈谈有争议的实验。这些 API 通常由 Chrome 团队提出，使浏览器能够使用蓝牙、写入本地文件以及在后台与服务器同步内容。对于其中的每一个，Safari 和 Firefox 都表示他们打算完全忽略 API，从不实施它，因为安全、隐私和电池寿命问题。首先，我确实认为 Chromium 在推动新 API 并在达成适当共识之前发布它们过于激进。就 Web 标准达成共识非常重要，而且通常感觉 Google 的团队更愿意立即发布新的 API，而不是花时间与其他供应商合作并发布正确的 API。

也就是说，他们提出的许多有争议的 API——从 Web 蓝牙到文件系统访问——显然都在利用真正的用例和真正的需求。通读对 https://twitter.com/jensimmons/status/1418920407642656775（来自 Apple 的 Web Dev Evangelist）的回复，关于 Firefox 对文件系统访问 API 或 WebMIDI 的讨论的评论，或 Safari 的 Web 推送问题。在辩论的背后，有大量热情的开发人员，他们兴奋地在这些技术的基础上构建产品，并努力为他们获得更广泛的支持。鉴于对这些功能的真正需求，并且 Chrome 热衷于发布它们，这对 Safari、Firefox 和其他人来说是一个非常大的问题。我非常赞同围绕这些功能存在安全和隐私问题的论点。不幸的是，Safari 和 Firefox 生活在一个领先的浏览器中，市场份额远远大于它们的总和，绝对会满足需求并发布这些新的 API。在其他供应商完全阻止这些功能进入网络的情况下，没有任何合理的选择。在许多情况下，它们已经存在。只有一个世界才能阻止他们超越 Chrome 65% 的市场份额（约 70%，包括所有基于 Chromium 的浏览器，或约 80% 的桌面浏览器）。渐进增强是一种经常用作解决此类 Web 兼容性问题的方法。不幸的是，在领先的浏览器构建了一个不能被 polyfill 的流行特性，而少数浏览器试图无限期地忽略它的情况下，渐进增强意味着：如果它是一个有价值的特性，Web 开发人员会在可用时使用它，但有些其他浏览器的回退行为

Web 开发人员发布了“在 Chrome/Edge/Opera 中效果最佳”的通知，以鼓励用户获得最佳体验 这并不是说每个网站都会使用这些闪亮的新 API——它们大多与 Web 应用程序用例隔离。但在某些方面更糟：您的普通用户不会安装新浏览器来阅读新闻文章，但如果它从他们的聊天应用程序（后台推送）向他们提供可靠的通知，那么他们可能会更容易使用他们每天在工作中使用的 webapp（本机文件系统），或者如果需要设置新的蓝牙小工具（网络蓝牙）。一旦他们为一件事切换，就会显着增加他们为所有事情切换的变化。您可能会想“我不在乎 - 我不会切换到 Chrome，我不想要使用这些 API 的 web 应用程序”。那没关系。与将切换到工作的最佳工具的用户组相比，永远不会违反原则使用 Chrome 的用户比例微乎其微。如果 Chromium 真的比其他浏览器引擎功能更强大，那么用户就会转向 Chromium，随着替代浏览器的市场份额缩小，开发人员开始忽视它，无论您想要哪种非 Chromium 浏览器，您对整个网络的体验都会变得更糟使用或访问的网页。在 Safari 的情况下，如果支持 Safari 很容易并且他们有很好的 Web 开发人员善意可以借鉴，那么这种风险就会降低。回到 Firefox 与 IE 的早期，Firefox 很小的初始市场份额问题不大，因为 Web 开发人员会积极努力确保他们的网站在那里工作，因为它是一个很好的支持和使用的浏览器。不幸的是（请参阅本文的前两节）Safari 不容易支持，而且绝对没有 Web 开发人员的善意可以依赖。所有这些都不是理论上的 - 这在今天明显发生。这些功能非常流行，以至于它们现在正在网络上的真实产品中使用，而上述过程正是正在发生的事情。例如，如果您购买 Espruino（一种流行的可编程 IoT 小工具），推荐的开发流程是他们的基于 Web 的 IDE，它使用 Web 蓝牙，并且需要基于 Chromium 的浏览器：

同样，Excalidraw（一种流行的在线白板工具）仅为具有文件系统访问 API（仅限 Chromium）的浏览器提供更好的 UX，Godot 引擎（一种开源游戏引擎）现在正在构建一个需要文件系统的基于 Web 的编辑器访问 API 支持（仅限 Chromium）以方便保存和加载，Noteflight（一种流行的音乐创作服务）关闭了他们现有的 MIDI 适配器，并将他们的主要工作流程移至 Web MIDI（仅限 Chromium）。这些 API 已经是网络结构的一部分。这些都是流行的 web 应用程序（Noteflight 有 600 万用户，Excalidraw 有 22,000 个 github 星），很多用户都想使用它们，而且它们的核心功能只能在 Chromium 中运行良好。当然，现在还为时尚早，可能的现实并不是浏览器生态系统会在此结束时真正崩溃。尽管 Firefox 和 Safari 担心，如果一个 API 真的起飞并达到临界质量，现实是他们将不得不按原样实施这些 API，否则就有与现实世界的网络不兼容的风险。这是一个稍微好一点的结果——我们仍然有多个兼容的浏览器——但只是非常温和：在这一点上，他们无意中允许谷歌单方面设置网络标准。我们应该避免这种情况。这描绘了一幅惨淡的画面。今天的一个可取之处是 Apple 阻止在 iOS 上使用任何非 WebKit 引擎，以保护该环境，而且 iOS 市场（至少在美国）足够大，这意味着必须优先考虑 Safari。然而不幸的是，苹果目前正处于反垄断斗争中，允许在 iOS 上使用替代浏览器引擎是......