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 > On 6 Mar 2026, at 01:17, Mason Freed <[email protected]> wrote: > > Thanks for the message. I see that it was copy/pasted into a number of > different forums (e.g. this bug > <https://issues.chromium.org/issues/435623334#comment32>, this WebKit bug > <https://bugs.webkit.org/show_bug.cgi?id=309238>, this WHATWG issue > <https://github.com/whatwg/html/issues/12107#issuecomment-4003261298>, 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 > <https://www.npmjs.com/package/xslt-polyfill> would fill the need, or if the > XML/XSLT producing equipment cannot be updated, then the polyfill browser > extension > <https://chromewebstore.google.com/detail/xslt-polyfill/hlahhpnhgficldhfioiafojgdhcppklm> > 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 > > On Thursday, March 5, 2026 at 8:13:44 AM UTC-8 Alex Kharichev wrote: >> 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: >> >> retaining XSLT support, at least behind an enterprise policy or flag, >> >> or providing a long‑term compatibility mode for controlled environments, >> >> 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. >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B5CA697D-33F8-437F-A5FB-4C3357F48DFF%40ndmsystems.com.
