It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”.

Having flashbacks of “<!--[if IE 6]> <script src="fix-ie6.js"></script> <![endif]-->”

https://issues.chromium.org/issues/451401343 tracks work needed in the upstream xml-rs repository, so it seems like the team is working on addressing issues that would affect standards compliance.

Disclaimer: I work on Chrome and have occasionally dabbled in libxml2/libxslt in the past, but I'm not directly involved in any of the current work.

> This is a lot more concerning.

I'm not so sure that's problematic. Probably browser just aren't a great platform for doing a lot of XML processing at this point.

Preserving the half implemented frozen state of the early 2000s really doesn't really serve anyone except those maintaining legacy applications from that era. I can see why they are pulling out complex C++ code related to all this.

It's the natural conclusion of XHTML being sidelined in favor of HTML 5 about 15-20 years ago. The whole web service bubble, bloated namespace processing, and all the other complexity that came with that just has a lot of gnarly libraries associated with it. The world kind of has moved on since then.

From a security point of view it's probably a good idea to reduce the attack surface a bit by moving to a Rust based implementation. What use cases remain for XML parsing in a browser if XSLT support is removed? I guess some parsing from javascript. In which case you could argue that the usual solution in the JS world of using polyfills and e.g. wasm libraries might provide a valid/good enough alternative or migration path.

> Removing XSLT from browsers was long overdue

> Google is willing to remove standards-compliant XML support as well.

> They're the same picture.

To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well, it's dashed inconvenient to maintain a WASM layer for a dependency that is not safe to vendor any more as a C dependency" is not the kind of servant-oriented mentality that made the web great, not just as a platform to build on, but as a platform to emulate.

> Currently, they seem to favor xml-rs which only implements a subset of XML.

Which seems to be a sane decision given the XML language allows for data blow-ups[^0]. I'm not sure what specific subset of XML `xml-rs` implements, but to me it seems insane to fully implement XML because of this.

[^0]: https://en.wikipedia.org/wiki/Billion_laughs_attack

I think it might make more sense to use WebAssembly and make them as extensions which are included by default (many other things possibly should also be made as extensions rather than built-in functions). The same can be done for picture formats, etc. This would improve security while also improving the versatility (since you can replace parts of things), if the extension mechanism would have these capabilities.

(However, I also think that generally you should not require too many features, if it can be avoided, whether those features are JavaScripts, TLS, WebAssembly, CSS, and XSLT. However, they can be useful in many circumstances despite that.)

Given that you have experience working on libxslt, why do you think they should have removed the spec entirely rather than improving the current implementation or moving towards modern XSLT 3?

I was somewhat confused and irritated by the lack of a clear frontrunner crate for XML support in rust. I get that xml isn't sexy, but still.

> Currently, they seem to favor xml-rs which only implements a subset of XML.

What in particular do you find objectionable about this implementation? It's only claiming to be an XML parser, it isn't claiming to validate against a DTD or Schema.

The XML standard is very complex and broad, I would be surprised if anyone has implemented it in it's entirety beyond a company like Microsoft or Oracle. Even then I would question it.

At the end of the day, much of XML is hard if not impossible to use or maintain. A lot of it was defined without much thought given to practicality and for most developers they will never had to deal with a lot of it's eccentricities.

What's long overdue is them updating to a modern version of XSLT.

> JavaScript is better than XSLT in every way

Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious.

The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application.

Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook.

It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

JavaScript is ever evolving and it means you need to stick to one of the two browsers (WebKit or Firefox) and keep upgrading. XSLT hasn't changed in years. It's an actual standard instead of an evolving one.

I know that other independent browsers that I used to use back in the day just gave up because the pace of divergence pushed by the major implementations meant that it wasn't feasible to keep up independently.

I still miss Konqueror.

Your link is just the abstract, I had to hunt for the full talk:

https://www.youtube.com/watch?v=U1kc7fcF5Ao

But it is quite interesting and especially learning about the security problems of the document() function (described @ 19:40-25:38) made me feel more convinced that removing XSLT is a good decision.

> Actually, you can make an RSS feed user-browsable by using JavaScript instead

Say I have an XML document that uses XSLT, how do I modify it to apply your suggestion?

I've previously suggested the XML stylesheet tag should allow

    <?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>

But with the implementation available today, I see no way to provide a first-class XSLT-like experience with JS.

No you can't, since opening an RSS feed won't run a javascript.

> by using JavaScript instead

I think you're entirely missing the point of RSS by saying that. RSS doesn't and should require NOT Javascript.

Now feeds could somehow be written in some bastard HTML5 directly, but please don't bring Javascript in that debate.

XSLT allows to transform a XML document into an HTML presentation, without the need for javascript, that's its purpose.

> In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser"

Wow. I can see the proposed scrapping of XSLT being a huge problem for all of the seven people who do this.

The sites that will be broken are disproportionately important though. Congress.gov/govinfo.gov, weather.gov, europa.gov, plus dozens of sites for libraries, and universities.

Looking only at how many sites use a feature gives you an incomplete view. If a feature were only used by Wikipedia, it'd still be inappropriate to deprecate it with a breaking change and a short (1yr) migration window. You work with the important users to retire it and then start pulling the plug publicly to notify everyone you might have missed.

Of course built-in support for RSS would be better. But what are the chances of that happening?

> Google Reader deprecation probably hurt RSS more than anything else

And, indeed, if the protocol was one killer app deprecation and removal away from being obsolete, the problem was the use case, not the protocol.

(Personally, I don't think RSS is dead; it's very much alive in podcasting. What's dead is people consuming content from specific sites as a subscription model instead of getting most of their input slop-melanged in through their social media feeds; they don't care about the source of the info, they just want the info. I don't think that's something we fix with improved RSS support; it's a behavior issue looking for a better experience than Facebook, not for everyone to wake up one day and decide to install their own feed reader and stop browsing Facebook or Twitter or even Mastodon for links all day).

My guess is that a lot of the controversy is simply because this is one of the first times that a major web feature has been removed from the web standards. For the past 20+ years, people have grown to expect that any page they make will remain viewable indefinitely. It doesn't matter that most people don't like XSLT, or that barely any sites use it. Removing XSLT does break some websites and that violates their expectation, so they get mad at it reflexively.

As someone who's interested in sustainable open source development, I also find the circumstances around the deprecation to be interesting and worth talking about. The XSLT implementation used by all the browsers is a 25 year old C library whose maintainer recently resigned due to having to constantly deal with security bugs reported by large companies who don't provide any financial contribution or meaningful assistance to the project. It seems like the browser vendors were fine with the status quo of having XSLT support as long as they didn't have to contribute any resources to it. As soon as that free maintenance went away and they were faced with either paying someone to continue maintenance or writing a new XSLT library in a safer language, they weren't willing to pay the market value for what it would cost to do this and decided to drop the feature instead.

What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning.

But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.

Yeah, the idea that it's some kind of foundation of the "open web" is quite silly.

I've used XSLT plenty for transforming XML data for enterprises but that's all backend stuff.

Until this whole kerfuffle I never knew there was support for it in the browser in the first place. Nor, it seems, did most people.

If there's some enterprise software that uses it to transform some XML that an API produces into something else client-side, relying on a polyfill seems perfectly reasonable. Or just move that data transformation to the back-end.

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable.

It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that.

I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user?

https://www.rss.style/

> I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them.

I used it to develop a website because I'm not a programmer, but I still want to have some basic templates on my webpage without having to set up a dev environment or a static site generator. XML and XSLT extend HTML _just enough_ to let me do some fun things without me having to become a full-on programmer.

All browsers ever implemented was XSLT 1.0, from 1999. There were 2.0 and 3.0 for which there is an open source Java based implementation (Saxon) but this never made it into libxslt and/or browsers!

Imagine you have users that want to view an XML document as a report of some kind. You can easily do this right now by having them upload a document and attaching a stylesheet to it. I do this to let people view after-game reports for a video game (Nebulous: Fleet Command). They come in as XML and I transform them to HTML. Now I do this all client-side using the browser support for XSLT and about 10 lines of javascript because I don't want to pay for and run a server for file uploads. But if I did the XSLT support in the browser would make it truly trivial to do.

Now this obviously isn't critical infrastructure, but it sucks getting stepped on and I'm getting stepped on by the removal of XSLT.

I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.

If you have a lot of xml data and need an UI that does complex operations that scream xpath it would be rather spectacular if it could be done without much of a back end, in the browser without js.

I'm not good enough with XSLT to know if it is worth creating the problem that fits the solution.

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees.

Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that.

[1] Yes, I already know about your one European law example that you only found out exists because of this drama.

The case for JPEG XL is much better than that for XSLT. On the other hand, people who program in C will always be a little terrified of XML and everything around it since the parsing code will be complex and vulnerable.

If you really want to improve the simplicity, there are better ways to do so rather than excluding Gopher.

(Also, they could make XSLT (and many other things that are built-in) into an extension instead, therefore making the core system more simpler.)

The company that invented "Web Bluetooth" doesn't have a leg to stand on whining about "immense complexity" in having to maintain old stable features in their browser implementation.

"Steering for more simplicity" would be a political decision. Keeping it is also a political decision.

Removing a feature that is used, while possibly making chrome more "simple", also forces all the users of that feature to react to it, lest their efforts are lost to incompatibility. There is no way this can not be a political decision, given that either way one side will have to cope with the downsides of whatever is (or isn't) done.

PS: I don't know how much the feature is actually used, but my rationale should apply to any X where X is a feature considered to be pruned.

I think that "market demands" is a bit of a misnomer. RSS was (and remains) too tech-y for the mainstream.

If browser vendors had made it easy for mainstream users, would there have been as much "market demand"?

Between killing off Google Reader and failing to support RSS/Atom, Google handed social media to Facebook et al.

>Google has both done more for and invested more into progressing the open web than anyone else.

One could also make that case about Microsoft with Microsoft office in the '90s. Embrace extend extinguish always involves being a contributor in the beginning.

>Blink is open source and modular. Maintaining a fork is much less effort than the alternative of maintaining a different browser engine.

Yeah and winning Asia Physical 100 is easier than winning a World's Strongest Man competition, and standing in a frying pan is preferable to jumping in a fire.

I'm baffled by appeals to the open source nature of Blink and Chromium to suggest that they're positive indicators of an open web that any random Joe could jump in and participate in. That's only the case if you're capable of the monumental weightlifting that comes with the task.

I agree with everything, but just to be clear:

> This is what web developers want

I don't think it is what web developers want, it is what customers expect.

Of course there are plenty of situation where the page is totally bloated and could be much leaner, but the overall trend to build web applications instead of web pages is dictated by user expectations and, as a consequence, requirements.

> They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead.

How does that become a market demand to remove RSS? There are tons of features within browsers which most users don't use. But they do no harm staying there.

> but deprecating XSLT is a rare opportunity to shrink the surface area of the web’s “API” without upsetting too many people

There's a lot of back and forth on every discussion about XSLT removal. I don't know if I would categorize that as 'without upsetting too many people'

I tried the JS polyfill on some of the basic XSLT that I wrote, and it only kinda worked. I can't imagine how it would fail on anything with any complexity.

Yes they are going to support it because there are modern libraries that do.

They're obviously in on it. /s

Cutting us Linux users off the Web.

XHTML does have some advantages compared with ordinary HTML, such as the parsing being more consistent, since the file will specify where literal text is used and which commands are or are not a block that is expected to contain other things.

(It could still try to render in case of an error, but display the error message as well, perhaps.)

I was all in on the concept of XHTML back in the day because it seemed obviously superior to chaotic, messy HTML. Nothing got me off that bandwagon as effectively as me converting a web app to emit pristine, validated XHTML and learning that no 2 browsers could process it the same way. Forget pixel-perfect layout and all that jazz. I couldn’t even get them to display the whole page reliably.

That’s because they didn’t want you to know about it. Hence letting it languish for 20 years and 2 major versions. The players doing this have been intentionally doing it for a few decades.

me too

"Was" is the key here. FTP has been obsolete for 20 years.

Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH.

Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.

Their business model is selling ads. They don't give a rats ass about the open web.

> put binary blobs in your browser outside the security sandbox

There are reasons to do this sometimes, but usually it would be better to put them inside of the security sandbox (if the security sandbox can be designed in a good way).

The user (or system administrator) could manually install and configure any native code extensions (without needing to recompile the entire browser), but sandboxed VM codes would also be available and would be used for most stuff, rather than the native code.

XML is not so good for most of the things it was used for, and JSON has some problems too (I prefer DER), but Google is doing many bad things with WWW and not only things relating to XML, whether or not XML is good.

Have to get everyone off Windows first. If you can do that, switching to Ladybird should be easy.

the article doesn't say kind things about it..

Just in time for Apple to buy it.