Should we remove XSLT from the web platform?
### What is the issue with the HTML Standard? XSLT v1.0, which all browsers adhere to, was [standardized in 1999](https://www.w3.org/TR/xslt-10/). In the meantime, XSLT has evolved to v2.0 and v3.0, adding features, and growing apart from the old version frozen into browsers. This lack of advancement, coupled with the rise of JavaScript libraries and frameworks that offer more flexible and powerful DOM manipulation, has led to a significant [decline](https://chromestatus.com/metrics/feature/timeline/popularity/78) in the use of client-side XSLT. Its role within the web browser has been largely superseded by JavaScript-based technologies such as JSON+React. The underlying libraries that browsers use to process these transformations (e.g. [libxslt](https://github.com/GNOME/libxslt) in Chromium) are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent [high-profile security exploits](https://www.offensivecon.org/speakers/2025/ivan-fratric.html) that continue to put browser users at risk. For these reasons, I’d like to raise the question of whether we should deprecate
Posted by mfreed7 on Aug 1, 2025, 10:13 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
Should we remove XSLT from the web platform?
### What is the issue with the HTML Standard? XSLT v1.0, which all browsers adhere to, was [standardized in 1999](https://www.w3.org/TR/xslt-10/). In the meantime, XSLT has evolved to v2.0 and v3.0, adding features, and growing apart from the old version frozen into browsers. This lack of advancement, coupled with the rise of JavaScript libraries and frameworks that offer more flexible and powerful DOM manipulation, has led to a significant [decline](https://chromestatus.com/metrics/feature/timeline/popularity/78) in the use of client-side XSLT. Its role within the web browser has been largely superseded by JavaScript-based technologies such as JSON+React. The underlying libraries that browsers use to process these transformations (e.g. [libxslt](https://github.com/GNOME/libxslt) in Chromium) are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent [high-profile security exploits](https://www.offensivecon.org/speakers/2025/ivan-fratric.html) that continue to put browser users at risk. For these reasons, I’d like to raise the question of whether we should deprecate
Comments (0)
No comments yet. Start the discussion.