Request to retain XSLT support due to telecom CPE architecture and non‑upgradable device ecosystem

[Alex Kharichev]

I am submitting this to document a significant real‑world impact of removing native XSLT support from browsers.

Our company operates a large set of enterprise systems built around a unified XML API layer. This API is used for machine‑to‑machine communication across all backend systems in our organization. It is intentionally designed to be deterministic, schema‑driven, and free of JavaScript dependencies to meet long‑term stability, auditability, and compliance requirements.

In the telecom environment, this architecture is not optional. We support consumer, SOHO, and SMB routers (both Wi‑Fi and non‑Wi‑Fi), and many of these devices rely on the same XML API for configuration, monitoring, and diagnostics. These devices are deployed in the field for many years, and many cannot be upgraded or replaced.

For human users, we rely on browser‑side XSLT to render these XML responses into practical, feature‑rich user interfaces. This approach is used extensively across our internal enterprise tools and also in several smaller public‑facing applications.

The scale and operational importance are substantial:

• Two major customers generate approximately 150 requests per second per server.

• The architecture has been in continuous production since 2011, with no planned retirement.

• The same XML API is consumed by physical telecom devices and third‑party systems, many of which cannot be updated to support alternative formats or workflows.

The benefits of this architecture are critical in telecom environments:

• A single canonical XML source of truth for both machine and human clients.

• No duplication of business logic between backend, frontend, and device firmware.

• A very low attack surface, since the XSLT UI loads minimal JavaScript and operates within strict CORS and security policies.

• Predictable behavior in controlled enterprise and embedded environments.

• Long‑term maintainability without dependency churn, which is essential for devices with 7–15 year lifespans.

Removing XSLT breaks this architecture entirely. Replacing it with JavaScript or server‑side rendering is not a viable alternative:

• It would require rewriting a large number of internal tools that have been stable for over a decade.

• It would force us to duplicate business logic currently expressed in XSLT.

• It would introduce new security and compliance risks due to JavaScript execution.

• It would break compatibility with existing routers and embedded devices that rely on the same XML responses and cannot be updated.

This is not a niche or legacy use case. It is a core architectural pattern across telecom CPE systems, and it has proven reliable, secure, and efficient for many years. The cost and risk of forced migration are extremely high, and in many cases impossible due to non‑upgradable hardware.

I respectfully request that browser vendors consider:

1. retaining XSLT support, at least behind an enterprise policy or flag,

2. or providing a long‑term compatibility mode for controlled environments,

3. or supporting a sandboxed, maintained XSLT engine (e.g., via WebAssembly).

Without such options, a large class of telecom devices and XML‑based enterprise systems will lose their only practical browser‑native UI layer, and many deployed devices will be left without a functional interface.

Thank you for taking this feedback into account.

[Mason Freed]

Thanks for the message. I see that it was copy/pasted into a number of different forums (e.g. this bug, this WebKit bug, this WHATWG issue, etc.) and I'd like to consolidate that. I'll reach out to you privately by email to see if I can help with the migration.

In short form, I have some questions. For example, the XML machine-to-machine portions of your application would seem unaffected. We're not deprecating XML. For human-centered browser-side XSLT, it seems like the polyfill would fill the need, or if the XML/XSLT producing equipment cannot be updated, then the polyfill browser extension could be installed on the client side. If the client side browser also cannot be updated, there won't be an issue either, since a pinned version of Chromium won't have its XSLT removed. I'm also a bit curious also about the mention of security concerns with Javascript execution, combined with the mention of the XSLT UI using "minimal Javascript".

Again, I'll reach out privately to see if I can help further.

Thanks,

Mason

[Alex Kharichev]

Hello Mason,

I’ve been following the news about XSLT support being removed across all major browsers, and this is extremely concerning for us. The systems we provide, along with the integrations built on top of them, rely entirely on XML+XSLT for their user‑facing interfaces.

So I tried to post my cry into all the browser-engine forums and groups I was able to.

> I'm also a bit curious also about the mention of security concerns with Javascript execution, combined with the mention of the XSLT UI using "minimal Javascript".

Regarding your question about JavaScript: our current UI uses only minimal JS, and the concern is not about that usage. The concern is that replacing XSLT with a JavaScript‑based UI layer would require building a parallel interface from scratch. That would introduce a large amount of new code, new security exposure, and a very high risk of regressions and inconsistencies with existing business processes.

I have not been able to find anything resembling the polyfill approach I described earlier — a PWA with a WebWorker that intercepts and proxy‑transforms XML fetch requests. Without something like that, the only fallback appears to be re‑implementing the entire human‑oriented interface in HTML+JS. For us, that is a massive and disruptive undertaking. In the simplest cases, third‑party software simply redirects a user to an API method with some arguments pre‑filled, and all further interaction depends entirely on the XML+XSLT rendering in the browser. Re‑creating this behavior outside XSLT would be extremely challenging.

I appreciate your willingness to help, and looking forward to continue the discussion.

Regards,

Alex

[Mason Freed]

On Fri, Mar 6, 2026 at 1:02 AM Alex Kharichev <m...@ndmsystems.com> wrote:

I’ve been following the news about XSLT support being removed across all major browsers, and this is extremely concerning for us. The systems we provide, along with the integrations built on top of them, rely entirely on XML+XSLT for their user‑facing interfaces.

So I tried to post my cry into all the browser-engine forums and groups I was able to.

I understand! And sorry this deprecation is concerning - I'll try to help as best I can.

 

> I'm also a bit curious also about the mention of security concerns with Javascript execution, combined with the mention of the XSLT UI using "minimal Javascript".

Regarding your question about JavaScript: our current UI uses only minimal JS, and the concern is not about that usage. The concern is that replacing XSLT with a JavaScript‑based UI layer would require building a parallel interface from scratch. That would introduce a large amount of new code, new security exposure, and a very high risk of regressions and inconsistencies with existing business processes.

Again, let's follow up by email (we've already started that). But for the other readers here - while replacing XSLT with HTML/Javascript is a great long term plan, my hope is that the polyfill is an "easy" one-line addition to your source XML (or the browser via extension) that might allow you to tackle the longer term plan at your leisure (or never).  

 

I have not been able to find anything resembling the polyfill approach I described earlier — a PWA with a WebWorker that intercepts and proxy‑transforms XML fetch requests. Without something like that, the only fallback appears to be re‑implementing the entire human‑oriented interface in HTML+JS. For us, that is a massive and disruptive undertaking. In the simplest cases, third‑party software simply redirects a user to an API method with some arguments pre‑filled, and all further interaction depends entirely on the XML+XSLT rendering in the browser. Re‑creating this behavior outside XSLT would be extremely challenging.

I'd like to understand this a bit more. Currently, `fetch()` requests don't run XSLT transforms inline. You must manually use `XSLTProcessor()` on the fetch result, from JavaScript. So a PWA that does that would be new territory, and not something that (I would think!) would help patch any existing code. Again, see the comments above regarding the polyfill. It can be added as a single line to an existing XML file that contains an XSLT stylesheet, and it automatically performs the transform, assuming the browser lacks native support. Since it's a one-line change to the source, it feels like it should be easier than any of the options you mentioned. I'd like to understand why that approach won't work for you so we can add any missing functionality.

 

I appreciate your willingness to help, and looking forward to continue the discussion.

Thanks for the conversation about this and for helping me understand your use cases.

Thanks,

Mason