xslt_polyfill

The removal was discussed here: https://news.ycombinator.com/item?id=45873434 No need to imagine a polyfil, they already exist: https://github.com/mfreed7/xslt_polyfill

> In 2019, a few months after the initial release of Scratch 3, Scratch discovered that SVGs can contain <script> tags that Scratch would cause to be executed when the SVG loads. This is known as an XSS. > Example from Scratch's test suite: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" xmlns="http://www.w3.org/2000/svg"> <circle cx="250" cy="250" r="50" fill="red" /> <script type="text/javascript"><![CDATA[ alert('from the svg!') ]]></script> </svg> Is this really an issue? This is the method that the chrome teams polyfill to replace XSLT suggests you do. https://github.com/mfreed7/xslt_polyfill/tree/main#usage

xslt-polyfill.min.js is 1.3 MB on its own https://github.com/mfreed7/xslt_polyfill/blob/main/xslt-poly...

Multiple MB? I'm looking at: https://github.com/mfreed7/xslt_polyfill Which uses: https://github.com/DesignLiquido/xslt-processor/tree/main But they don't look that heavy. Am I missing something? Megabytes of JS would be enormous.

Since the XSLTProcessor feature can be realized with a Polyfill (https://github.com/mfreed7/xslt_polyfill), I find myself agreeing with Google. Btw, I love this page! Highly entertaining, yet at the same time use of XSLT.

> Cant you just do the xslt transformation server-side? For my Atom feed, sure. I'm already special-casing browsers for my Atom feed [0], so it wouldn't really be too difficult to modify that to just return HTML instead. And as others mentioned, you can style RSS/Atom directly with CSS [1]. For my Stardew Valley Item Finder web app, no. I specifically designed that web app to work offline (as an installable PWA), so anything server-side won't work. I'll probably end up adding the JS/wasm polyfill [2] to that when Chrome finally removes support, but the web app previously had zero dependencies, so I'm a little bit annoyed that I'll have to add a 2MB dependency. [0]: https://github.com/gucci-on-fleek/maxchernoff.ca/blob/8d3538... [1]: https://news.ycombinator.com/item?id=45874305 [2]: https://github.com/mfreed7/xslt_polyfill

The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.

Looks like there is a WASM polyfill for XSLT based on libxslt: https://github.com/mfreed7/xslt_polyfill To me this is the best way forward, I used to like XSLT quite a bit but the world has moved on and I get browser maintainers not wanting to try and maintain that extra native code surface area. It seems like the browser should be incorporating many libraries as WASM to mitigate exploits and surface area such as XSLT and rarely used image formats etc. Then only do the native versions for widely used features where it's worth the effort to maintain and vet them.

https://github.com/mfreed7/xslt_polyfill/pull/5 - it will be able to do this soon.

https://github.com/mfreed7/xslt_polyfill/pull/5 - someone's made a PR that looks like it would allow Mason's polyfill to work directly from the XML file.