Google 决定杀死 XSLT,Web 标准契约破裂

Death Comes for XSLT

Google 决定杀死 XSLT,Web 标准契约破裂

去年万圣节,Google 联手其他浏览器厂商决定移除 XSLT 支持,这违背了 Web 标准中‘不破坏网络’的社会契约。作为回应,我创建了 XSLT.RIP 网站,它完全由 XSLT 构建,注定在 Google 执行删除时一同‘死亡’。Chromium 系浏览器已开始向用户注入警告横幅,甚至被指为‘中间人攻击’。Google 将责任推给网站维护者,却忘了正是他们主动打破了 Web 的向后兼容性原则。

Google 决定背弃承诺并破坏 Web,XSLT.RIP 很快将失效,而我只能坐视 Google 亲手将其摧毁。
  1. kenferry

    这说法似乎过于绝对了。XSLT 当初是个听起来不错的主意,但实际操作起来相当别扭(就像很多 XML 技术一样),从未真正普及开来。我们真的有必要把每一个失败的实验都永远挂在浏览器厂商的脖子上吗?我宁愿看到他们把精力花在大家真正关心的事情上。

    来自其中一个问题追踪器的原话:

    “虽然不破坏现有网页内容很重要,但防止安全漏洞同样关键。XSLT 在浏览器中一直处于维护模式,并且一直是持续不断的安全问题来源。”

  2. IFC_LLC

    我还记得 2006 年我把个人网站更新为通过 XML/XSLT 运行时的情景。当时的 Opera 浏览器不支持这项功能,所以只有 Firefox 用户能完整使用。那也是我唯一一次尝试 XSLT。

    后来我转到了 HTML,之后就再没想过这项技术。有时候我不得不使用 XML,因为当时我是 .NET 2.0/3.5 的狂热粉,但我记得后来微软在 .NET Core 等项目中全面转向了 JSON。

    从那以后我就再没用过 XML。Markdown 如今已成为我个人文档的黄金标准。我宁愿在 Markdown 严格的限制下工作,也不愿花时间去支持 XML 中无穷无尽的各种变体。

    我真诚地请求大家帮我开开眼,讲讲 XSLT 的必要性。我完全愿意承认自己错了。谁能给我解释一下它具体是怎么用的吗?

  3. nayuki

    大约 15 到 30 年前,我曾在 Windows 资源管理器、Internet Explorer 和 Mozilla Firefox 中使用过 FTP。当时确实很方便。FTP 也在主流浏览器中被毫不留情地砍掉了。你仍然可以通过其他软件或底层库来使用它。后来我读了协议规范,意识到它的设计其实很糟糕——不过至少相比 HTTP 那铺天盖地的功能,它还算是简单简洁。

  4. telebub

    我觉得整个移除方案有点偷懒。

    理论上,某些逻辑可能会声明 BOM/DOM 的某些方面必须是 JS,以便进行内省(introspection)等,但反过来却不一定成立。

    没有什么能规定像 XSLT 这样的东西必须比在标准 JS 虚拟机中用一点小 trick 实现得更“原生”,所以将事情委托给一个二流的、仅用于向后兼容的层级,其带来的独特安全优势可能微乎其微。

  5. sheepscreek

    我对使用 XSLT 有着美好的回忆。当时那确实是个很酷的想法。

    我想世界已经几乎远离了 XML(至少对浏览器而言是这样,尽管仍有不少人还在享受 SOAP API)。结果,XSLT 也就随之没落了。

同日更多故事

2026-11-04