What is the issue with the HTML Standard?

Background

This is a follow-up to #11523. That issue raises concerns regarding security issues, code maintainability, and the complexity of aging browser code currently used for rendering XML with XSLT stylesheets. I highly recommend reading through that issue first as it includes a good background of XSLT on the web as well as the specific concerns that may lead to deprecating XSLT as the most prudent option for browser vendors.

As a reminder, please read the whatwg Code of Conduct. This issue is intended to be a discussion of alternatives to deprecations and how the concerns raised in #11523 may be handled to mitigate the risks for both browser maintainers and users. Please stay on topic here by discussing the pros and cons of XSLT v3.0 support, alternatives, etc. Discussions related to assumed motivations, specific browser vendors, etc. aren’t relevant here and will likely just result in the issue being locked, preventing us from having the important discussion in public here.

What is the issue with the HTML Standard?

The XSLT 1.0 specification was originally standardized in 1999. Though the W3C has subsequently defined 2.0 and 3.0 specifications for XSLT, most browsers today never added support beyond v1.0. In addition, cross-browser functionality for XSLT is incomplete with certain features like having open issues dating back over two decades with no fix in sight. I raise longstanding issues in general as a challenge related to the concerns of maintainability and relatively little use of XSLT 1.0 today, not as a concern over prioritization or resource allocation by browser vendors.

The question of use of XSLT today, raised in #11523, raises an interesting question. Is the low usage statistics of XSLT today an indication of the usefulness of the specification in today’s web, or an indication of the challenges of dealing with v1.0 limitations and bugs? Deprecating XSLT entirely assumes that the issue related to use relies only on XSLT itself and that use would go effectively unchanged if the improvements from v2.0 and v3.0 were available in browsers. Anecdotally I can say that I have run into blocking issues with v1.0 itself; I built a blogging CMS as a hobby project that was designed to lean entirely on XSLT to render CMS users’ RSS feeds to complete, customizable websites. Between vendor-specific XSLT bugs and the limitations of a now 25 year old spec, I found that I would only be able to build the CMS with a more recent version of the XSLT specification.

Alternatives to deprecation

I don’t intend to prescribe a solution here! Instead, these open questions (and others I missed) are important when weighing the relative merits with regards to deprecating XSLT entirely.

• Are there external libraries that browsers could adopt in order to gain v3.0 support without building and maintaining the specification in house?
• Are there security concerns relevant to v3.0, or are the concerns limited to the v1.0 specification and current implementations?
• Is there an approach that would allow browser vendors to use a single implementation for XSLT, combining efforts to reduce cost on each vendor?