Comment by ummonk
3 months ago
No, that would indeed be reasonable, but the proposal is to remove XSLT from the standard and remove Chrome support for XSLT entirely, forcing websites to adopt the polyfill themselves.
3 months ago
No, that would indeed be reasonable, but the proposal is to remove XSLT from the standard and remove Chrome support for XSLT entirely, forcing websites to adopt the polyfill themselves.
Which is, to me, silly. If you ship the polyfill then there's no discussion to be had. It works just the same as it always has for users and it's as secure as V8, no aging native codebase with memory corruption bugs to worry about.
> It works just the same as it always has for users
No it doesn't. An HTML page constructed with XSLT written 10 years ago will suddenly break when browsers remove XSLT. The webmaster needs to add the polyfill themselves. If the webmaster doesn't do that, then the page breaks.
From a user perspective, it only remains the same as before if the webmaster adopts the polyfill. From the web developer perspective, this is a breaking change that requires action. "shipping the polyfill" requires changes on many many sites - some of which have not needed to change in many years.
It may also be difficult to do. I'm not sure what their proposed solution is, but often these are static XML files that include an XSLT stylesheet - difficult to put JS in there.
I meant the browser shipping the polyfill themselves. I'm in agreement with you.
At the moment, XSLT in a browser doesn't depend on Javascript, so works even if JS is turned off. Using a polyfill instead will mean that XSLT will only work if JS is turned on.
That depends how the browsers implement it, no? Much of modern browser's user interface is also built using web technologies including JS and that doesn't break if you "disable JS".