Hacker News Reader

Comment by genxy | Hacker News Reader

This is what the browser vendors should have done, with links to the wasm modules for doing the transforming. It would have been better this way.

View on HN

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.

I mean now, instead of ripping it out and breaking sites, they should have implemnented the fallback via wasm.

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.

Reply on news.ycombinator.com