[jopsen]

Isn't this something that could be implemented using javascript?

I don't think anyone is arguing that XSLT has to be fast.

You could probably compile libxslt to wasm, run it when loading xml with xslt, and be done.

Does XSLT affect the DOM after processing, isn't it just a dumb preprocessing step, where the render xhtml is what becomes the DOM.

[NoGravitas]

It could be. The meaningful argument is over whether the javascript polyfill should be built into the browser (in which case, browser support remains the same as it ever was, they just swap out a fast but insecure implementation for a slow but secure one), or whether site operators, principally podcast hosts, should be required to integrate it into their sites and serve it.

The first strategy is obviously correct, but Google wants strategy 2.

[realityking]

As discussed in the GitHub thread, strategy two is fundamentally flawed because there’s no other way to make an XML document human readable in today’s browsers. (CSS is close but lacking some capabilities)

So site operators who rely on this feature today are not merely asked to load a polyfill but to fundamentally change the structure of their website - without necessarily getting to the same result in the end.