Baseline:重新思考浏览器支持的新方式

多年来,前端开发者一直在纠结一个过时的问题:“我们支持哪些浏览器版本?”这种提问方式在 Internet Explorer 占主导地位且浏览器每年更新一次的时代是合理的。而如今,Chrome 和 Firefox 每隔几周就会发布新版本。Safari 也定期更新。旧的思维模型已经不再适用。

Web Platform Baseline 提供了一种更好的方法。你不再需要追踪浏览器版本,而是追踪功能可用性。本文将解释 Baseline 的工作原理、它对现代浏览器兼容性的重要意义,以及如何在你的项目中应用它。

什么是 Web Platform Baseline?

Baseline 是一个跨厂商倡议,由 Google、Microsoft、Apple 和 Mozilla 通过 W3C WebDX 社区组共同支持。你可以在 MDN、web.dev 和 Can I Use 上找到 Baseline 指示器。

Baseline 回答了一个简单的问题:我能否在各个浏览器中安全地使用这个功能?

它定义了一组核心浏览器:

• Chrome(桌面版和 Android 版)
• Edge
• Firefox(桌面版和 Android 版)
• Safari(macOS 和 iOS)

当一个功能在所有这些浏览器中都能工作时,它就获得了 Baseline 状态。

三种可用性状态

Baseline 功能分为三个类别:

有限可用(Limited availability):该功能存在于某些浏览器中,但并非全部。使用时需谨慎或配合 polyfill。

新近可用(Newly available):该功能在每个核心浏览器的所有稳定版本中都能工作。它具有互操作性,但较为新近。

广泛可用(Widely available):该功能已在所有核心浏览器中存在至少 30 个月。大多数用户都可以访问。

“广泛可用”的 30 个月门槛并非随意设定。它考虑了不会立即更新的用户、旧设备以及继承自主要引擎的下游浏览器。30 个月后,一个功能通常已经覆盖了几乎所有人。

为什么这种思维模式转变很重要

传统的基于版本的策略会产生问题。当 Firefox 在单个项目期间发布六个主要版本时,“Firefox 的最后两个版本”意味着什么?目标一直在变化。

功能可用性思维解决了这个问题。你不再问”我们支持哪些浏览器版本?“,而是问”这个功能是 Baseline 吗?”

这种转变带来三个实际好处:

更清晰的决策。 查看 MDN 上的 Baseline 指示器。如果显示”广泛可用”,就可以放心使用该功能。无需对版本号进行心算。

更好的利益相关者沟通。 “我们使用在所有浏览器中可用 30 个月以上的功能”比”Chrome、Firefox 和 Safari 的最后两个版本,加上 Firefox ESR,再加上全球使用率超过 0.5% 的任何版本”更容易解释。

提高一致性。 团队做出的主观判断更少。策略在项目间统一应用。

如何在实践中应用 Baseline

采用 Baseline 遵循一个简单的模式:

对于核心功能,依赖广泛可用的特性。这些构成你的基础。没有现代浏览器的用户仍然能获得可用的体验。

对于渐进式改进,使用带有特性检测的新近可用特性。将它们包装在 @supports 块或 JavaScript 检查中。使用旧浏览器的用户获得基础体验,而其他人获得升级版本。

/* 广泛可用的回退方案 */
.container {
  max-width: 100%;
}

/* 新近可用的增强 */
@supports (container-type: inline-size) {
  .container {
    container-type: inline-size;
  }
}

上面的 CSS 是渐进增强的一个清晰示例。每个浏览器都理解 max-width: 100%。同时支持容器查询的浏览器会获得更强大的布局。对任何人都不会造成破坏。

将 Baseline 集成到你的工具中

Baseline 在开发工具中得到越来越多的支持。Browserslist 现在直接支持 Baseline 查询(例如,针对”广泛可用”功能或特定的 Baseline 年份),帮助保持构建工具与支持策略的一致性。browserslist-config-baseline 包提供了现成的配置,如果你不想自己编写查询的话。

ESLint 的 CSS 支持(@eslint/css)包含一个 use-baseline 规则,可以标记超出你选择的 Baseline 阈值的属性。虽然不完美——它对渐进增强模式可能过于严格——但它表明了生态系统的发展方向。

随着 Baseline 采用率的增长,预计与构建工具、linter 和框架的集成会更加紧密。

Baseline 是默认选择,而非保证

Baseline 提供了一个强有力的起点,但它不能替代判断。边缘情况是存在的。一个功能可能是 Baseline,但在某个浏览器中存在重大 bug。无障碍性问题可能需要超出兼容性数据的测试。具有锁定浏览器的企业环境需要单独考虑。

将 Baseline 作为你的默认假设,然后在风险较高时进行验证。

结论

Web Platform Baseline 代表了一个根本性转变:从基于版本的支持矩阵转向功能可用性思维。它减少了认知负担,改善了团队沟通,并与现代浏览器的实际工作方式保持一致。

首先在使用新功能之前检查 MDN 上的 Baseline 状态。采用”广泛可用”作为你的基础。通过渐进增强分层加入”新近可用”的功能。让工具跟上来支持你的工作流程。

问题不在于你支持哪些浏览器。而在于你需要哪些功能。

常见问题

Baseline 与检查 Can I Use 有何不同?

Can I Use 显示单个功能在各浏览器中的支持百分比。Baseline 基于这些数据,但提供了一个单一的、标准化的判断——有限可用、新近可用或广泛可用——由所有主要浏览器厂商共同认可。它将决策从解释兼容性表格简化为检查一个状态标签。

Baseline 是否涵盖 JavaScript API,还是仅涵盖 CSS 属性?

Baseline 广泛涵盖 Web 平台功能,包括 CSS 属性、JavaScript API、HTML 元素以及 Web API(如 Fetch API 或 Web Animations API)。任何由 WebDX 社区组跟踪并在所有核心浏览器中支持的功能都可以获得 Baseline 状态。

如果我采用 Baseline,是否应该停止使用 Browserslist?

不一定。Browserslist 仍然驱动着 Autoprefixer 和 Babel 等工具,但它现在直接支持 Baseline 查询。你可以在 Browserslist 中针对 Baseline 阈值,或使用 browserslist-config-baseline 将构建管道与你的策略对齐。

如果一个广泛可用的功能在某个浏览器中存在已知 bug,我该怎么办?

Baseline 状态并不保证在每个浏览器中都没有 bug。如果已知 bug 影响了你的用例,请专门测试它并应用有针对性的解决方法。Baseline 是一个可靠的默认选择,但关键功能仍需要针对实际浏览器行为进行手动验证。