Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
In an XML document a "processing instruction" can trigger the XSLT processor to transform the document in another format.
So an XML document would be parsed and processed by the XML engine, trigger XSLT processor, which would then trigger again the XML processor again and the HTML processor.
So XSLT processing for XML/XHTML is deeply embedded. Dropping it removes a lot of corner cases that AI is good at exploiting.
The cool thing with a wasm-based xslt implementation is there is no need for the browser vendors to gate-keep it. Just use the implementation you prefer.
Except XSLT dates back to the late 90s. WASM was not even a glint in the eyes of its creators. Mozilla even used XSLT internally to drive the GUI for their browser iirc. I think based on that there is a good reason it was incorporated into browsers.
If they were going to implement it themselves it would be unnecessary to faff around with webassembly. They could just keep the native code implementation that they already have.
The problem is that XSLT has so few users that the browser writers don't want to waste any more time on it. Those few people who wrote their site around it will have to either rewrite it to use something else or add some third party webassembly implementation themselves.
