I wrote a few months ago about the proxy war by Google against the open web by means of XSLT. Unsurprisingly, Google has been moving forward on the deprecation, still without providing a solid justification on the reasons why other than “we've been leeching off a FLOSS library for which we've finally found enough security bugs to use as an excuse”. They do not explain why they haven't decided to fix the security issues in the library instead, or adopt a more modern library written in a safe language, taking the opportunity to upgrade XSLT support to a more recent, powerful and easier-to-use revision of the standard.
Instead, what they do is to provide a “polyfill”, a piece of JavaScript that can allegedly used to supplant the functionality. Curiously, however, they do not plan to ship such alternative in-browser, which would allow a transparent transition without even a need to talk about XSLT at all. No, they specifically refuse to do it, and instead are requesting anyone still relying on XSLT to replace the invocation of the XSLT with a non-standard invocation of the JavaScript polyfill that should replace it.
This means that at least one of these two things are true:
the polyfill is not, in fact, sufficient to cover all the use cases previously covered by the built-in support for XSLT, and insofar as it's not, they (Google) do not intend to invest resources in maintaining it, meaning that the task is being dumped on web developers ( IOW , Google is removing a feature that is going to create more work for web developers just to provide the same functionality that they used to have from the browsers); insofar as the polyfill is sufficient to replace the XSLT support in the browser, the policy to not ship it as a replacement confirms that the security issues in the XSLT library used in Chrome were nothing more than excuses to give the final blow to RSS and any other XML format that is still the backbone of an independent web.
As I have mentioned in the Fediverse thread I wrote before this long-form article, there's an obvious parallel here with the events that I already mentioned in my previous article: when Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser, they did this on presumed technical grounds (citing as usual security and maintenance costs, but despite paid lip service to their importance for an open and interoperable web, they didn't provide any official replacement for the functionality, directing users instead to a number of add-ons that provided similar functionality, none of which are written or supported by Mozilla. Compare and contrast with their Pocket integration that they force-installed everywhere before ultimately killing the service
Actions, as they say, speak louder than words. When a company claims that a service or feature they are removing can be still accessed by other means, but do not streamline such access said alternative, and instead require their users to do the work necessary to access it, you can rest assured that beyond any word of support they may coat their actions with there is a plain and direct intent at sabotaging said feature, and you can rest assured that any of the excuses brought forward to defend the choice are nothing but lies to cover a vested interest in sabotaging the adoption of the service or feature: the intent is for you to not use that feature at all, because they have a financial interest in you not using it.
And the best defense against that is to attack, and push the use of that feature even harder.
This is the gist of my Fediverse thread.
Do not install the polyfill. Do not change your XML files to load it. Instead, flood their issue tracker with requests to bring back in-browser XSLT support. Report failed support for XSLT as a broken in browsers, because this is not a website issue.
I will not comply. As I have for years continued using MathML, SVG and SMIL (sometimes even all together) despite Google's intent on their deprecation, I will keep using XSLT, and in fact will look for new opportunities to rely on it. At most, I'll set up an infobox warning users reading my site about their browser's potential brokenness and inability to follow standards, just like I've done for MathML and SMIL (you can see such infoboxes in the page I linked above). And just like ultimately I was proven right (after several years, Google ended up fixing both their SMIL and their MathML support in Chrome), my expectation is that, particularly with more of us pushing through, the standards will once again prevail.
... continue reading