On Fri, Mar 6, 2026 at 1:02 AM Alex Kharichev <[email protected]> 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 <https://www.npmjs.com/package/xslt-polyfill> is an "easy" one-line addition to your source XML (or the browser via extension <https://chromewebstore.google.com/detail/xslt-polyfill/hlahhpnhgficldhfioiafojgdhcppklm>) 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 > > 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: >> >> 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. >> > > -- 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/CAM%3DNeDjFWuLudm4oRW3Cy_WaTbYT0tB_fCUOevymBS9QOFfqzg%40mail.gmail.com.
