Chrome 和 Edge 正在移除 XSLT：哪些会坏掉，哪些不会

原文 ↗ Hacker News 讨论 ↗

Chrome 和 Edge 正在弃用内置 XSLT 支持，这引发了人们对依赖 XML 的网站、样式化 RSS/Atom feed 以及依赖客户端转换的边缘工作流可能出现故障的担忧。支持移除的人认为 XSLT 很少使用、维护复杂，而且由于老旧 XML 库的存在，安全和攻击面问题不容忽视；而反对者则惋惜这种强大、声明式的模板工具，以及它作为被放弃的 XML/XHTML 网络愿景象征的意义。有人提出的替代方案包括服务器端转换、基于 JavaScript 或 WebAssembly 的 XSLT 引擎，或更简单的 CSS 样式化，但许多人认为并不存在真正一对一的替代品。

变更范围

  • Chrome 正在弃用并移除内置 XSLT；作为 Chromium 分支的 Edge 预计也会跟进。
  • Firefox 目前仍可使用，但会记录警告，并且也有关于 XSLT 的“intent to unship”。
  • 直接影响是：浏览器内 的 XSLT 将消失；服务器端 XSLT 不受影响。

给出的移除理由

  • 这是一个遗留、很少使用的功能，且攻击面大而复杂。
  • 底层 XML 库年代久远、维护不足，并且有漏洞历史。
  • 为数十亿用户维护这段代码被认为成本高昂。
  • 有人认为 LLM 让维护更便宜；也有人反驳说，这同样降低了发现漏洞的成本，并没有消除安全和维护成本。

质疑与批评

  • 有些人认为这是浏览器单一文化的表现：厂商“就因为懒得管所以直接把东西拿掉”。
  • 也有人把这看作类似 Flash 退场的模式：构造安全叙事来为移除不方便的技术辩护。
  • 另一些人则回应说，几乎没人再使用或维护 XSLT，指望长期支持并不现实。

影响与破坏

  • 基于 XML+XSLT 的界面（例如某些 IIS 报表、TEI/XML 阅读器、样式化的 RSS/Atom feed、基于 XSLT 的博客）将在 Chromium 系浏览器中失效或降级。
  • Chrome 已经在使用 XSLT 时显示醒目的警告。
  • 使用 XSLT 的政府和监管网站也被指出存在风险（相关问题链接）。

替代方案与迁移路径

  • 在服务器端完成 XSLT 转换，并提供纯 HTML。
  • 在客户端使用基于 JS 或 WebAssembly 的 XSLT 处理器（不过包装代码和示例仍然不成熟）。
  • 直接用 CSS 为 XML/RSS 设置样式，但要接受局限性。
  • 用基于 JS 的技术（例如 document.currentScript + DOM APIs）或其他模板引擎替换 XSLT 模板化。

更广泛的 XML/XHTML/XSLT 争论

  • 有些人哀叹曾经“XML/XHTML 未来”的消失：schema、客户端模板化以及更清晰的模块化。
  • 另一些人则认为 XHTML/XML/XSLT 工具链差、学习曲线陡、语法冗长，而且从未获得大规模采用。
  • 严格 XML/XHTML 与宽容 HTML 之间的争论非常激烈；严格性既被视为优点（清晰报错），也被视为障碍（内容脆弱）。