Intent to Deprecate and Remove Xslt

XSLT is no more "baggage" than HTML itself. Removing it in no way "moves the web forward". And integrating technologies part of the current hype cycle, which very well may disappear in a year, is a terrible idea.

TLDR: QEMU but much simpler and only WASM need be supported.

Firstly, it puts a huge burden of non-value-adding work onto developers and the organisations they work for.

Secondly it would lead to even higher frequency and prevalence of people inventing their own half-arsed ways of doing things that used to be in the box. Nobody would think about standard usability affordances, accessibility, etc.

Thirdly, it would simply move the attack surface into an emergent library ecosystem without really solving anything.

Fourthly, it would increase website payloads even further. Developers have historically been awful at using bandwidth efficiently (still a concern in many scenarios due to connectivity limitations and costs), and we don’t need to offer more opportunities for them to demonstrate how terrible and undisciplined they are at it.

Fifthly, not everyone wants or needs (or should!) to learn web assembly in the same way that not everyone wants or needs to learn x86/64 assembly, ARM assembly, C or Rust.

Sixthly, it would lead to a huge amount of retooling and rewriting which, yes, to some extent would happen anyway because, apparently, we all love endless churn masquerading as progress, but it would be considerably worse.

The web would become significantly buggier and more unusable as a result of all of the above.

Part of the reason google chrome won the browser wars is because they are willing to make decisions like this. Kitchen sink software is bad software.

The writing has been on the wall for a long while. Mozilla hasn't stepped up, Google hasn't stepped up, GNOME hasn't stepped up, Oracle hasn't stepped up, etc. Maybe its just a format that once anyone gets involved with, they no longer want to be involved with it any further.

I believe they didn’t just because most of politicians don’t know anything about software.

Being aware of the problems that “governmatization” of open source can bring it still is something I expect to be picked up by countries.

I think this sets a concerning precedent for future deprecations, where parts of the web platform are rugpulled from developers because it's convenient for the browser vendors.

I feel like there is a bit of a no true scotsman to this.

XSLT was always kind of on the side. If FTP or flash weren't part of the web platform than i dont know that xslt is either. Flash might not be "standard" but it certainly had more users in its heyday than xslt ever did.

Does removal of tls 1.1 count here? Its all kind of a matter of definitions.

Personally i always thought the <keygen> tag was really cool.

I’m not a Chrome dev but I think they have decent reasons for going this way.

On the other… I’m still a bit uncomfortable with the proposed change because it reads as another example of Google unilaterally dictating the future of the web, which I’ve never liked or supported.

Feeling quite conflicted.

Flash was the web technology.

API’s should provide content in the format asked of them. CSS should be used to style that content.

This is largely solved in RFC-6838 which is about “how media types, representation and the interoperability problem is solved”. https://datatracker.ietf.org/doc/rfc6838/

Already supported by .NET Web APIs, Django, Spring, Node, Laravel, RoR, etc.

Less mature ecosystems like Golang have solutions, they’re just very much patch-work/RYO.

Or even use OpenResty or njs in Nginx, which puts the transformation in the web service layer and not the web application layer. So your data might be JSON blob, it’ll convert to HTML in real-time. Something similar can be achieved elsewhere like Apache using mod_lua etc.

I think bastardising one format (HTML), to support another format (JSON), is probably not the right move. We’ve already done that with stuff like media queries which have been abused for fingerprinting, or “has” CSS selectors for shitty layout hacks by devs who refuse to fix the underlying structure.

And XSL is used to validate invoice documents.

Typically, these use XSLT on the backend to transform the content to HTML to be sent to the web browser.

And there's RSS which was mentioned in the previous discussions. Podcasts will typically have HTML renderings of that data, but if you opened the RSS in a web browser you could use XSLT to provide a user-friendly view of the content.

XSLT can also be used to provide fallback rendering for unsupported content, such as converting MathML to HTML for browsers without support. -- Chrome as of 109 supports MathML Core, but doesn't support the content markup (used for more semantic markup of common constructs like N-ary sum, integrals, etc.), so would still need something like XSLT to convert that markup to the presentation markup supported by Chrome.

The browser vendors are arguing XSLT is neither good - it's adoption has always been lacking because of complexity and has now become a niche technology because better alternatives exist - nor working, see the mentioned security and maintenance issues. I think they have a good point there.

I think it is because nobody, excepts a handful of people around the world, feels the need to use XSLT in lieu of CSS. Hence, CSS has evolved over time while XSLT has not.

This is how the world works: technology advances and old things become obsolete over time.

Why would the public sector feel bound to support it as opposed to pivot in the same direction the winds are blowing?

Outside the idiocy of this particular administration in the US, gov is pivoting toward more commercial norms (with compliance/etc for gov cloud and etc compliance).

It is true that public bodies are less concerned with profitability, which changes how they make decisions around deprecations and removals, but being cost-effective is still important for them, especially when budgets are low and need is high. In situations like that, it's not uncommon for, say, a service to get cut so that funding can be reallocated elsewhere where it's more needed.

I don't think publicly funding this sort of work would necessarily significantly change the equation here. The costs of XSLT are relatively high because of its complexity and the natural security risks that arise from that complexity. Meanwhile, it is very rarely used, and where it is used, there are better alternatives (generally loading a sandboxed library rather than using the built-in tooling).

How many people ever do this?

Easy: ignore due to no content-type header.

now how about that:

Chrome voluntarily decides to disjoint self from parts of the web where it can't take profits - saying they are not in fashion ..

- and if then, actually no one would like to have to follow ever again anything like that ?. (ocean is _big_ and.. blue)

... for who?

Maybe for a few small things like JSON, I suppose, but not for any of the major standards. And not just as in they implement a superset of the standards - every browser implements a distinct set of each standard that is neither a subset nor a superset.

I'm still not a fan of Chrome nor the effect it has on the web.

But I see less of that money but much better used - to support any of open, independent, not for profit, conforming to standards browsers instead - in not following what a big corporation says and want.