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/ad6a1269-86e4-4822-9bc1-d398bd9d87f2n%40chromium.org.
