polyxslt：给浏览器补上一个轻量级 XSLT 处理器
内容提要
为应对Chrome等浏览器移除内建XSLT支持，作者开发了纯JavaScript轻量级XSLT 1.0处理器polyxslt，支持RSS、Atom和sitemap常用功能子集，Brotli压缩后约10KB。它保留xml-stylesheet指令，通过XHTML script加载，行为以libxslt为准，经三引擎测试，MIT开源。sitemap因校验问题改用构建时预渲染HTML。
延伸解读
为什么需要 polyxslt：浏览器 XSLT 支持即将退场
Chrome 已公布弃用和移除 XSLT 的计划：从 Chrome 158（2026年11月17日）起，多数用户的 XSLT 将停止工作，Chrome 176 则会彻底移除。Gecko 和 WebKit 也表态支持移除。这意味着依赖浏览器内建 XSLT 的 RSS、Atom 或 sitemap 样式表将无法继续工作。polyxslt 正是在这一背景下，用纯 JavaScript 实现 XSLT 1.0 常用子集，为未来浏览器补齐这一能力。
体积与功能取舍：10KB 的轻量方案适合谁
polyxslt 经 Brotli 压缩后仅约 10 KB，运行时无外部依赖，只使用 ES2022 特性。它支持 xsl:template、xsl:apply-templates、xsl:for-each、xsl:sort、xsl:choose、xsl:value-of、xsl:copy-of、xsl:element、xsl:attribute、xsl:variable 以及 XPath 1.0 大部分核心函数。但不支持 xsl:import、xsl:include、xsl:call-template、xsl:pa
部署方式：RSS/Atom 可用，sitemap 为何例外
RSS 2.0 和 Atom 规范都允许在根元素中加入其他命名空间的扩展元素，因此可以把 XHTML script 作为 feed 根元素的子元素来加载 polyxslt。但 sitemap 官方模式对扩展元素要求 strict 校验，额外加入的 XHTML script 无法通过严格校验。作者选择保持 sitemap 内容不变，改为在构建时用 xsltproc 预渲染一份伴生 HTML，再由 Web 服务器根据请求头选择返回 XML 还是 HTML。
行为对齐与安全边界：以 libxslt 为准，但非通用净化器
polyxslt 在规范允许实现自行选择或 libxslt 与规范不一致时，大体沿用 xsltproc 的实际行为，以减少既有样式表的渲染偏差。例如支持科学计数法、按 libxslt 规则转换数字、xsl:sort 默认不使用语言相关排序。安全方面，自动替换 XML 页面内容时默认执行结果中的脚本，以兼容原生 XSLT 行为；严格模式可移除脚本、框架、事件处理属性等，但作者强调它并非通用 HTML 净化器，处理不可信输入仍应配合 CSP。
Q&A
polyxslt 是什么？它解决了什么问题？
polyxslt 是一个纯 JavaScript 实现的轻量级 XSLT 1.0 处理器，用于在未来不再提供内建 XSLT 的现代浏览器中补齐这一功能。它主要应对 Chrome 等浏览器移除内建 XSLT 支持的计划，支持展示 RSS、Atom 订阅和 sitemap 所需的常用 XSLT 功能子集。
polyxslt 的体积有多大？支持哪些 XSLT 指令？
polyxslt 经 Brotli 压缩后仅约 10 KB，运行时无外部依赖。它支持的指令包括 xsl:template、xsl:apply-templates、xsl:for-each、xsl:sort、xsl:choose / xsl:if、xsl:value-of、xsl:copy-of、xsl:element / xsl:attribute、xsl:variable，以及 XPath 1.0 的大部分核心函数。
polyxslt 不支持哪些 XSLT 特性？遇到不支持的指令会怎样？
polyxslt 目前不支持 xsl:import / xsl:include、xsl:call-template / xsl:param、xsl:key、xsl:number 以及 mode 属性。如果遇到不支持的指令，它会明确报错中止，而不是静默忽略。
如何在 XML 文档中使用 polyxslt？
保留 XML 文档开头的 <?xml-stylesheet?> 处理指令，在根元素内部加一个 XHTML 命名空间的 script 元素，指向 polyxslt 的构建产物路径。例如在 RSS 根元素下添加 <script xmlns="http://www.w3.org/1999/xhtml" src="/js/xslt-polyfill.min.js"></script>。样式表应只输出展示内容，避免把加载 polyfill 的脚本复制到结果中。
为什么本站的 sitemap.xml 没有添加 polyxslt？
因为 sitemap 官方模式在扩展槽位要求 strict 校验，额外加入的 XHTML <script> 不能通过严格校验。考虑到 sitemap 主要给搜索引擎使用，作者选择保持其内容不变，避免引入额外的扩展校验和客户端兼容性问题。为了兼顾人类访客，主题在构建时用 xsltproc 预渲染了一份伴生 HTML，由 Web 服务器根据请求头选择响应。
polyxslt 在行为上以什么为基准？有哪些已知差异？
polyxslt 大体沿用 xsltproc（libxslt）的实际行为，以最大程度避免非预期的渲染偏差。已知差异包括：libxslt 按 UTF-8 字节顺序排序，polyxslt 按 JavaScript 字符串的 UTF-16 码元顺序排序，涉及补充平面字符与 U+E000–U+FFFF 的比较时可能不同；polyxslt 没有复现 HTML 解析器的所有纠错行为，也不会补上 libxslt 输出时可能产生的缩进空白。这些差异记录在 docs/DIVERGENCES.md 中。
polyxslt 在安全方面有哪些考虑？
polyxslt 在自动替换 XML 页面内容的模式下，默认会执行转换结果里的脚本，以兼容原生 XSLT 的展示行为。直接调用 transform 或 XSLTProcessor 时，返回的结果节点在调用方插入文档之前不会执行其中的脚本。另有一个默认关闭的严格模式，可通过脚本上的 data-strict 属性或 transform 的 { strict: true } 选项启用，打开后会从结果里去掉脚本、框架、嵌入对象、事件处理属性和 javascript: URL 等内容。但严格模式并非通用 HTML 净化器，处理不可信输入时应配合 CSP 使用。
