Look, I wouldn't want to be responsible for maintaining anything to do with XML or XSLT either. All the technical arguments outlined for removing support make sense. But can users really call it an "update" if you could view an XML/XSLT document in Internet Explorer 6 or Chrome 1 but not the newest version?

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.

> As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.

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.

Yeah… on the one hand I don’t care about XSLT, haven’t used it in more than 20 years, and never intend to use it again.

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.

XSLT is also a really problematic feature from an implementation perspective (albeit in a different way than showModalDialog or MutationObservers).

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

Maybe the blink or marquee tags? I’m pretty sure those don’t work anymore...

> As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.

Flash was the web technology.

> good and working parts are removed

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.

> One might think that as technology progresses more and more pieces of older technologies get revived and incorporated into the available tooling. Yet the very opposite thing happens: good and working parts are removed because the richest companies on Earth "cannot afford" to keep them.

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.

Pertinent to your point, he wanted to resurrect ancestors so that they, too, could participate in the general resurrection. The analogy being old technology resurrected to work alongside contemporary technology towards a shared goal.

> XSLT lets you build completely static websites without having to use copy paste or a static website generator to handle the common stuff like menus.

How many people ever do this?

Was there ever a good reason for XSLT to be an XML document itself? It was painful writing it.

> I defy google to not figure out what to index here:

Easy: ignore due to no content-type header.

cute :) (focused and instant)

I’m lost at “the public sector would have argued for some budget”. Xslt and libxslt are used across a no - trivial amount of deployments.

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).

I'm quite unconvinced by this - it seems very easy to come up with all sorts of counterexamples, particularly in terms of public infrastructure, but also all of public services are regularly cut if the organising body doesn't see that service as achieving its goals any more.

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).

This is why I've needed to use XLST, to style my personal RSS feed. Great guide for this: https://andrewstiefel.com/style-atom-xsl/ Looks like it's been raised on the whatwg issue too: https://github.com/whatwg/html/issues/11523#issuecomment-315...

extremely important? i use rss a lot and i have never seen anyone do this

For what it's worth, there does not exist a "standard internet browser," assuming that means an application that adheres to all relevant web standards. No piece of software exists (at least not publicly) that even adheres to the entirety of any single relevant web standard (e.g. HTML, CSS, ECMAScript, etc.), as far as I know.

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.

- as in Europe, I don't see neither how taxpayers money or users time (if still alive) could be forcibly used to cover the costs of some far away corporation savings (on bug fixing) and profit, downgrading then a lot into more costly, less maintainable, not standard solutions.

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.

Dude… no.

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.

That sounds awful! For a start, accessibility would get even worse than it already is. The browser may become more “minimal” and “simple” from the point of view of the implementer, but certainly not the user.

On the off chance that by “canvas” you didn’t mean all rendering (which is a terrible idea for reasons addressed by others) but only what is currently covered by <canvas>—the frame buffer approach is incompatible with GPU acceleration, so 3D would basically not be possible. For better or for worse, WebGL is pretty close to the minimum acceptable for that kind of functionality.

I think it sounds good to have that "on top" of what's already there. So that those who want to can use a lower level abstraction.

I like the idea but you could take it a step further and have just a core virtual machine that you could attach virtual (input/output) devices to. So then the canvas and audio would just be virtual devices that met some specification. Or say for example, you just want to listen to an audio playlist, you could attach an audio device, a keyboard and a terminal device (for feedback). A canvas device wouldn't necessarily be required (if there was no use for one). And it would be up to the user to attach the devices required by an application, or at least the user would have direct control.

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

Probably more due to the fact that browsers only support the 1999 XSLT 1.0, and no one has shown any interest in implementing XSLT 2.0 from 2001, or XSLT 3.0 from 2017. So there has been a sign of lack of desire since 2001 at minimum, likewise there is seemingly no attempt by anyone to document incompatibilities and push browsers to unify their incompatibilities like HTML, JS, and CSS.

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 would expect governments finally taking over.

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.

People are free to make their own browser if they want.

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.

It really is. It's extremely handy albeit a bit niche these days.

It's used a lot in the publishing industry, which stores the content in JATS and other similar XML markup. It's also used by the US government for bills, etc.

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.

Not just "still use", at least here in Germany our brand new e-invoicing system (mandatory since this year) is built on XML.

And XSL is used to validate invoice documents.

XML allows multiple trees in one file via namespaces, this is a big difference

> The lack of support of XSLT 2.0 in browsers is a major issue,

... for who?

Part of the issue is that XSLT in the browser is stuck at version 1.0 so lacks a lot of the improvements added in 2.0 and later that make working with it a lot nicer.

Why not just expose an HTML representation of the data? Why must it remain JSON, XML, CSV, Parquet, fixed length or tab delimited files, ProtoBuf, etc?

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.

They are only getting rid of xslt. You can still use <?xml-stylesheet with CSS

(?) - then more about the tactic: https://news.ycombinator.com/item?id=44994459 (web looks like nails for that tool we have)

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)

Wow, I couldn't disagree more.

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.