<?xml-stylesheet type="text/xsl" ?>

syntax

The PI grammar is defined by Associating Style Sheets with XML documents; the transformation semantics are XSLT 1.0 (W3C Recommendation, 1999). The removal targets the XSLT type values only:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>   <!-- removed -->
<?xml-stylesheet type="application/xslt+xml" href="demo.xsl"?>  <!-- removed -->
<?xml-stylesheet type="text/css" href="styles.css"?>  <!-- NOT removed -->
<page>
  <message>Hello World.</message>
</page>

what happens when disabled

1. Chrome receives the XML document and finds the XSLT processing instruction.
2. With the XSLT feature disabled, the PI is ignored: no transformation runs.
3. Chrome renders the raw XML document (its standard XML view) and shows a warning banner that links directly to an extension search page, so affected users can discover the XSLT polyfill extension.
4. A deprecation warning is logged to the console (from 143) and a deprecation report with id "XSLT" is emitted (see detection).

migration: one line of polyfill

The polyfill can be added to the XML document itself — a single <script> element (with the XHTML namespace declaration, required so the script executes in an XML document):

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
  <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>
  ...content...
</ROOT>

Mechanism: the script detects the XML document type and the XSLT PI, re-fetches the source document (to get the clean original byte stream), fetches the stylesheet, runs the WASM libxslt engine, and replaces the document's content with the transformed result. Scripts in the transformed output are re-created so they execute, and synthetic DOMContentLoaded/load events fire. For RSS/Atom feeds the added script is safe for feed readers because it sits as a direct child of the root element.

Documented limits for the PI path:

• CORS — stylesheet and xsl:include/xsl:import/document() resources load through fetch(); cross-origin stylesheets that native XSLT accepted can now be blocked. Host the stylesheet same-origin or serve CORS headers.
• Quirks — the replaced content lives in an XHTML document, which always renders in no-quirks mode; transformed HTML that relied on quirks rendering (no <!DOCTYPE>) can look different.
• Encoding — the single-file WASM build requires UTF-8.
• Loading latency — the WASM engine compiles on first use; the polyfill offers a window.xsltPolyfillSpinner hook for a loading indicator.

affected use cases and recommended paths

browser compatibility

No dedicated BCD entry exists for the processing instruction itself (the xslt web-feature covers the capability; webstatus.dev); treat this table as interim data compiled from the linked primary sources.

security and privacy

• The PI path is the riskiest half of the feature: it processes an attacker-supplied stylesheet through libxslt during page load, with no script required — the exploit class documented at OffensiveCon 2025.
• Native PI stylesheet loads were historically not CORS-bound; the polyfill's fetch()-based loads are CORS-checked, which is stricter (and the cause of most polyfill failures, per the ChromeStatus interop notes).
• The browser extension route grants a user-installed extension access to raw XML pages; weigh that against firmware updates for managed devices.