A lot of very old SPA like heavy applications use XSLT. Basically, enterprise web applications (not websites) that predate fetch, rest, and targeted or still target Internet Explorer 5/6.
There was a time where the standard way to build a highly interactive SPA was using SOAP services on the backend combined with iframes on the front end that executed XSLT in the background to update the DOM.
Obviously such an approach is extremely out of date and you won't find it on any websites you use. But, a lot of critical enterprise software was built this way and is kind of stuck like this.
At first glance the library of congress link appears to be using server side XSLT, which would not be affected by this proposal.
The congress one appears to be the first legit example i have seen.
At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.
> I am very sure the people at google are aware of the rss feed usage.
No. No they aren't. As you can see in the discussion: https://github.com/whatwg/html/issues/11523 where the engineer who proposed this literally updates his "analysis" as people point out use cases he missed.
Quote:
--- start quote ---
albertobeta: there is a real-world and modern use case from the podcasting industry, where I work. Collectively, we host over 4.5 million RSS feeds. Like many other podcast hosting companies, we use XSLT to beautify our raw feeds and make them easier to understand when viewed in a browser.
Thanks for all of the comments, details, and information on this issue. It's clear that XSLT (and talk of removing it) strikes a nerve with some folks. I've learned a lot from the posts here.
--- end quote ---
> Don't confuse people disagreeing with you with people not understanding you.
You're angry you didn't get your way, but the googler's decision seems logical, i think most software developers maintaining a large software platform would have made a similar decision given the evidence presented (as evidenced by other web browsers making the same one).
The only difference here between most software is that google operates somewhat in the open. In the corporate world there would be some customer service rep to shield devs from the special interest group's tantrum.
Well, it's Google who jumped at the opportunity citing their own counters and stats.
Just like they did the last time when they tried to remove confirm/prompt[1] and were surprised to see that their numbers don't paint the full picture, as literally explicitly explained in their own docs: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
You'd think that the devs of the world's most popular browser would have a little more care than just citing some numbers, ignoring all feedback, and moving forward with whatever they want to do?
Seriously, i doubt this.