I want native XSLT 3.0 and interactive XSLT support in browsers

I want browsers to natively support XSLT 3.0 — including the Interactive XSLT (IXSL) extension for event handling — so that declarative, standards-based data transformation can be used as a first-class approach to building web UIs.

Browsers currently ship only an aging implementation of XSLT 1.0 via the XSLTProcessor API. XSLT 3.0, standardised by the W3C in 2017, adds support for JSON input and output, streaming transformations, higher-order functions, and many other features that make it practical for modern web development. Meanwhile, the IXSL extension pioneered by Saxonica's Saxon-JS demonstrates that XSLT can be extended with event-handling primitives that allow stylesheets to respond to user interaction — turning a transformation language into a complete, reactive UI layer.

Web UIs are fundamentally data transformations: they take structured data and produce a rendered tree of elements, updating that tree in response to user events. XSLT was designed precisely for this task. It is a standardised, declarative, composable language with over two decades of real-world use. Modern JavaScript frameworks — React, Svelte, Web Components, JSX — effectively re-implement a subset of what XSLT already provides, but in an ad-hoc, non-interoperable way.

Native browser support for XSLT 3.0 and IXSL would:

• Allow XML and JSON data to be transformed directly in the browser without a JavaScript build step.
• Enable accessible, progressively enhanced server-side-rendered pages that use the same XSLT stylesheets on the server and in the client.
• Provide a standards-based alternative to proprietary component frameworks for teams whose data is already in XML (publishing, government, scientific data, legal documents, etc.).
• Reduce client-side JavaScript payload for data-heavy applications where the transformation logic currently runs in a JS library.

Saxon-JS already demonstrates that a high-quality XSLT 3.0 + IXSL implementation can be shipped as a JavaScript library. Native browser support would make it universally available, faster through engine-level optimisation, and accessible to developers who cannot or do not want to take on an additional library dependency.