Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support¹. If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance.

While it's important to not break existing web content, it's also important to prevent security vulnerabilities. XSLT has been in maintenance mode in browsers and has been an ongoing source of security issues. Features and technology are sometimes removed from browsers for this reason, even when doing so breaks some existing content. Examples: Mutation Events, window.showModalDialog(), keygen, plugins. The usage of XSLT is lower than that of Mutation Events at the time of their removal, and Flash was very commonly used.

If it turns out not to be possible to remove the feature, we’d like to replace our current implementation. The main requirements would be compatibility with existing web content, addressing memory safety security issues, and not regressing performance on non-XSLT content. We’ve seen some interest in sandboxing libxslt, and if something with that shape satisfied our normal production requirements we would ship it.

Law firms

Law firms here extensively utilize XSLT, and it is no wonder, because the contractors would rather utilize standards over and over, instead of hiring new developers of new nich in Ruby, Python, Lua, et cetera.

The most interesting thing, is that since, for whatever reason, FF had its XSLT broken, a couple of law firms which I am currently associated with, with overhaul 560 employees, do not have internet browsers (HTTP/HTML) installed, only Email, XMPP, and our in-house XSLT software to transform documents, which is weird to me.

Standards

As Information Architect Mr. Liam Quin states.

Sometimes standards succeed and sometimes not, but open architectures and standard formats and protocols protect your investment, making it easier to migrate when needed, and where the formats become popular, making skills, expert knowledge and software easier to acquire, reducing costs.

– Liam R. E. Quin

And he is correct!

XSLT beyond XSLT 1.0

Hence, I think that we should upgrade to XSLT 2.0, XSLT 3.0, and provide support for the upcoming XSLT 4.0.

XSLT 1.0

It was at an extended vaccation in Karpathos, Greece from the law firm which I was associated of at the time, and it was when I have experimented with the XSLTProcessor of yours, because your browsers were my routine browsers.

Interestingly, the malfunctioning XSLT implementations of yours have forced me to use Falkon and Otter Browser, in order to be able to experiment with ECMAScript module XSLTProcessor, and XSLT in general.

So, I think that you should fix your implementation of XSLT 1.0, both the built-in interpreter which does not appear to fail to execute directive "disable-output-escaping", which used to work, and also you should improve your implementation of the ECMAScript module "XSLTProcessor".

I have created a Greasemonkey script which utilizes XSLTProcessor, yet I had to substitute it with ECMAScript module "DOMParser", because your ECMAScropt module "XSLTProcessor" failed to execute upon that task.

Older version

https://openuserjs.org/scripts/sjehuda/Newspaper_(XMLHttpRequest)

Newer version

https://openuserjs.org/scripts/sjehuda/Newspaper

Once FF finally supports XSLT 3.0 at the very least, I will not be with Falkon, which is the closest to FF, as I am, today.

For record, to compensate on the non-functioning "disable-output-escaping" of "the engine gecko", add attribute "type" with value "html" or "xhtml" and utilize this code.

window.addEventListener('load', function() {
  // Scan for elements with indicators of HTML content.
  for (element of document.querySelectorAll("[type*='html']")) {
    // Check whether content has HTML elements.
    if (element.children.length < 1) {
      // Retrieve text content.
      plainContent = element.textContent;
      // Instatiate an HTML/XML object parser.
      domParser = new DOMParser();
      // Generate an HTML document.
      processedContent = domParser.parseFromString(plainContent, 'text/html');
      // Replace content by the new HTML document.
      element.innerHTML = processedContent.body.innerHTML
    }
  }
});

This is not the correct venue to talk about your law firm, or to report bugs or feature requests in Firefox.

Further off-topic comments will result in the issue being locked. Thank you for understanding.

I think it is a correct venue - we are FF users and we share the concerns outlined in this issue

@zcorpan, I'd say that most of that message was indeed off-topic. However, I believe that the core of it was on-topic: that the author believes that instead of deprecate XSLT, implement its later revisions. I did struggle to follow it, though.