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 will keep using XSLT, and in fact will look for new opportunities to rely on it.
This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.
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.
Sounds like EVERYBODY agrees that there isn't sufficient market value then. Even the original maintainer. And the that is indeed why the feature is being dropped: insufficient market value. Happy happy happy!
I don't think a maintainer refusing to answer spam issues from billion dollar corporations that contributes nothing back is evidence of no value to the maintainer. Unless you think FFmpeg has no market value, who has taken the same stance.
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.
It has nothing to do with the specifics of the technology. As a consumer of online content, I don't care one bit if it is styled with XSLT or CSS (though as a developer my condolences are with the author, if they worked with XSLT).
However, what I do care about is that it _remains viewable and usable_. Imagine if Microsoft Word one day decided you couldn't open .doc or .rtf files from the early 2000's? The browser vendors have decided that the web is now an application delivery platform where developers must polyfill backwards compatibility, past documents be damned.
And just as the article drives the point home, it doesn't have to be this way. They could just provide the polyfill within the browser, negating any purported security issues with ancient XML libraries.
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.
I would just do this on the server side. You can even do it statically when generating the XML. In fact until all the stuff about XSLT in browsers appeared recently, I didn't even know that browsers could do it.
Converting the contents of an Atom feed into (X)HTML means it's no longer a valid Atom feed. The same is true for many other document formats, such as flattened ODF.
Is an XLST page a valid atom feed? Is it really so terrible to have to two different pages -- one for the human readable version, and one for the XML version?
Yes, an <?xml-stylesheet href="..."?> directive is valid in every XML document. You can use CSS to get many of the benefits of XSLT here, but it doesn't let you map RSS @link attributes to HTML a/@href attributes, and CSS isn't designed for interactivity. That's a rather significant gap in functionality.
It is rather terrible to have two different pages, because that requires either server or toolchain support, and complicates testing. The XSLT approach was tried, tested, and KISS – provided you didn't have any insecure/secure context mismatches, or CORS issues, which would stop the XSL stylesheet from loading. (But that's less likely to spontaneously go wrong than an update to a PHP extension breaking your script.)
RSS and Atom feeds are at this point a solution looking for a problem.
I use RSS all the time... To keep up-to-date on podcasts. But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook.
> But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook.
I guess if you don't use social media or facebook you're out of luck?
I don't see why. You can always subscribe to a newspaper. Or just use RSS and a subscription tool since it didn't just go away.
What I'm saying, though, is if you don't use social media at this point you're already an outlier (I am, it should be noted, using the term broadly: you are using social media. Right now. Hacker News is in the same category as Facebook, Twitter, Mastodon, et. al. in this context: it's a place you go to get information instead of using a collection of RSS feeds, and I think the reason people do this instead of that may be instructive as to the ultimate fate of RSS for that use-case).
The circulation for my local newspaper is so small that they now get printed at a press a hundred miles away and are shipped in every morning to the handful of subscribers who are left. I don't even know the last time I saw a physical newspaper in person.
> Hacker News... it's a place you go to get information instead of using a collection of RSS feeds
No, it's a place I go to _in addition_ to RSS feeds. An anonymous news aggregator with web forum attached isn't really social media. Maybe some people hang out here to socialize, but that's not a use case for me
The relevant use case is you come here to see links people share and comment on them. That's sufficiently "social" in this context.
Contrasting the other use case you dabble in (that makes you an outlier) of pulling content from specific sources (I'm going to assume generating original content, not themselves link aggregators, otherwise this topic is moot) via RSS. Most people see that as redundant if they have access to something like HN, or Fark, or Reddit, or Facebook. RSS readers alone, in general, don't let you share your thoughts with other people reading the article, so it's not as popular a tool.
> The relevant use case is you come here to see links people share and comment on them. That's sufficiently "social" in this context.
Just having users submit links that other users can comment on doesn't make it social media. I can't follow particular users or topics, I can't leave myself a note about some user that I've had a positive or negative experience with, I can't ignore someone who I don't want to read, etc. Heck, usernames are so de-emphasized on this site that I almost always forget that they're there.
A rose by any other name. If you'd prefer I'd have said
"But for keeping up to date on news, people use link aggregation boards where other users post links to stuff on the web and then talk to each other about them. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Hacker News."
... that would be the same point. RSS, by itself, is a protocol for finding out some site created new content and is just not particularly compelling by itself for the average user when they can use "link aggregation boards where other users post links to stuff on the web and then talk to each othe about them" instead.
RSS hasn't gone anywhere. Every podcast my podcast player downloads is announced to it either via RSS or Atom feeds. It has just fallen by the wayside as the way people become aware of updates to websites with serial publication of content (in general: because most people get that information from peer-to-peer link sharing, like Facebook, Twitter, Mastodon, Fark, Reddit, Slashdot, or even this website).
They're not even removing the ability for the browser to render XML. They're just removing an in-browser formatter for XML (a feature that can be supported by server-side rendering or client-side polyfill).
Yes while their chosen formats directly aligned with their business get first class citizenship and suffer many larger and well known security issues. Xml will be next just wait.
What would that mean? XML is just text on the wire. If a browser stops supporting it... It's text on the wire. I slurp it in with JavaScript and parse it how I want.
The language in the browser for specifying what should show up and in what format is HTML and CSS. We can't remove them because we don't have anything to substitute; without them, there's just no displayable content.
Is your proposal that we replace those relatively heavyweight standards with something more primitive that we could then build the behavior on top of? I think there's meat on those bones. Quite frankly, the amount of work we do to push intent to fit the constraints of HTML and CSS in web apps is a little absurd relative to the frameworks and languages we have to do that in non-web widget toolkits. I'm not actually convinced that "Tk as an abstraction in the browser that we build HTML and CSS on top of" would be a bad thing (although we probably want to use something better than Tk, with more security guarantees).
... However, if we did that, we would really damage the accessibility story as it currently stands (since accessibility hinting is built on top of the HTML spec) and that's probably a bridge too far. We already have enough site developers who put zero thought into their accessibility; removing even the defaults HTML provides with its structure would be a bad call.
yes, but why???
Your on the website and you have a link to the syndicated feed, for the website your on, and you want to make they feed look good in the browser... so they can click the link to the website _you are already on_???
The argument you should be looking at the feed XML in the browser instead of the website is bonkers. They are not meant to replace the website coz if they were why have the website?!
But you are tech-savvy and know about RSS & feed readers and such like!
Think about it from a non-technical user's perspective: they click on a RSS link and get a wall of XML text. What are they going to do? Back button and move on. How are they ever going to get introduced to RSS and feed readers and such like?
I think a lot of feeds never get hit by a browser because there isn't a hyperlink to them. For example: HN has feeds, but no link in the HTML body, so I'm pretty confident they don't get browser hits. And no one who doesn't already know about feeds will ever use them.
I just checked and I’ve had 3 hits for my blog’s RSS feed from a legit-looking browser user agent string this year. Almost literally no one reads my site via RSS in the browser. Quite a few people fetch the feed from separate clients.
I wouldn’t spend 5 minutes making that feed look pretty for browser users because no one will ever see it. I don’t know who these mythical visitors are who 1) know what RSS is and 2) want to look at it in Chrome or Safari or Firefox.
What about people who don't "1) Know what RSS is"???
And what if you could make it friendly for them in 4 minutes? You could by dropping in a XSLT file and adding a single line to the XML file. I bet you could do it in 3 minutes.
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.
Yeah, but WHY?
If they are on the website, why would they want to look at the feed for the website, on the website, in the browser instead of just looking at the website? If the feed is so amazing, why have the website in the first place? Oh yeah, you need something to make the feed off :D
The Internet saves a lot more on storage and bandwidth costs by not shipping an XSLT implementation with every browser than it does by allowing Joe's Blog to present XML as an index.
I have arduinos with sensors providing their measurements as XML, with an external XSLT stylesheet to make them user-friendly. The arduinos have 2KB RAM and 16 MIPS.
Which build process are you talking about? Which XSLT library would you recommend for running on microcontrollers?
No because then it would not be an Atom feed. Atom is a syndication format, the successor to RSS. I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked.
This is why so many people find this objectionable. If you want to have a basic blog, you need some HTML docments and and RSS/Atom feed. The technologies required to do this are HTML for the documents and XSLT to format the feed. Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website.
So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader.
It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.
There are separate URLs for "https:" vs "http:" although they are usually the same content when both are available (although I have seen some where it isn't the same), although the compression (and some other stuff) is decided by headers. However, it might make sense to include some of these things optionally within the URL (within the authority section and/or scheme section somehow), for compression, version of the internet, version of the protocol, certificate pinning, etc, in a way that these things are easily delimited so that a program that understands this convention can ignore them. However, that might make a mess.
I had also defined a "hashed:" scheme for specifying the hash of the file that is referenced by the URL, and this is a scheme that includes another URL. (The "jar:" scheme is another one that also includes other URL, and is used for referencing files within a ZIP archive.)
> Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response?
The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.
> It's the same content, just supplied in a different format. It should be the same URL.
So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format.
> The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.
Just like protocol negotiation, HTTP has format negotiation and XML postprocessing for exactly the same reason.
> So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format
Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.
Similarly, it makes sense to return an XML with XSLT for most browsers and a degraded experience with just a simple text file for legacy browsers such as NCSA Mosaic or 2027's Google Chrome.
> Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.
So, you need a lot of cleverness on the browser to detect which format the client needs, and return the correct thing?
Kind of not the same situation as emitting an XML file and a chunk of XSLT with it, really.
If you're going to make the server clever, why not just make the server clever enough to return either an RSS feed or an HTML page depending on what it guesses the client wants?
> If you're going to make the server clever, why not just make the server clever enough to return either an RSS feed or an HTML page depending on what it guesses the client wants?
There's no cleverness involved, this is an inherent part of the HTTP protocol. But Chrome still advertises full support for XHTML and XML:
But importantly, for audio/video files, that's still just serving static files, which is very different from having to dynamically generate different files.
Then the server should supply the right format based on the `Accept` header, be it `application/rss+xml` or `application/atom+xml` or `text/xml` or `text/html`.
Even cheaper than shipping the client an XML and an XSLT is just shipping them the HTML the XSLT would output in the first place.
How many people out of the world's nearly eight billion population, would you estimate, are attempting to host their blog including HTML posts and RSS feeds on an Arduino?
I guess that tracks for Internet of Shitty Insecure Badly-Designed Things.
Come up with the worst possible way to present information over a web page.
What device with 2kB of RAM is going to generate any kind of useful RSS feed? Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?
> What device with 2kB of RAM is going to generate any kind of useful RSS feed?
Such devices usually don't generate RSS feeds, but e.g. sensor measurements as XML (which can be processed directly, or opened in a browser with XSLT to generate a website and an SVG chart from it)
> Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?
Because anything else will have >100× more power consumption?
Compare the power consumption of the atmega328p on an Arduino Uno 3 mentioned further up this thread, with the power consumption of literally any ARM chip smaller than the sort of thing you'd use in a laptop.
A static site cannot inspect headers. There is no HTML, or even JavaScript function you can put in a file to inspect the headers before the file is sent to the client.
A static site is a collection of static files. It doesn't need a server, you could just open it locally (in browsers that don't block file:// URI schemes). If you need some special configuration of the server, it is no longer a static site. The server is dynamically selecting which content is served.
Oh, difference in definitions. You mean "non-configurable web server." Because you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted.
But agreed; if your web server is just reflecting the filesystem, add this to the pile of "things that are hard with that kind of web server." But perhaps worth noting: even Apache and Python's http.server can select the file to emit based on the Accept header.
A static site is one that you can serve through static hosting, where you have no control over the web server or its configuration. There is not some extra thing which is a static site with dynamic content. “Static” means “doesn't change.” The document served doesn't change subject to the person receiving it. You are talking about a solution that is dynamic. That does change based on who is making the request.
>you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted
And this web-server configuration would not exist within the static site. The static site generator could not output it, therefore it is not a part of the static site. It is not contained within the files output by the static site generator. It is additional dynamic content added by the web server.
It breaks the fundamental aspect of a static site, that it can be deployed simply to any service without change to the content. Just upload a zip file, and you are done.
I get your meaning; I've just heard "static site" used to refer to a site where the content isn't dynamically computed at runtime, not a site where the server is doing a near-direct-mapping from the filesystem to the HTTP output.
> Just upload a zip file, and you are done.
This is actually how I serve my static sites via Dreamhost. The zipfile includes the content negotiation rules in the `.htaccess` file.
(Perhaps worth remembering: even the rule "the HTTP responses are generated by looking up a file matching the path in the URL and echoing that file as the body of the GET response" is still a per-server rule; there's no aspect of the HTTP spec that declares "The filesystem is directly mirrored to web access" is a thing. It's rather a protocol used by many simple web servers, and most of them allow overrides to do something slightly more complicated while being one step away from "this is just the identity function on whatever is in your filesystem, well, not technically the identity function because unless someone did something very naughty, I don't serve anything for http://example.com/../uhoh-now-i-am-in-your-user-directory").
> 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.
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.
> I will keep using XSLT, and in fact will look for new opportunities to rely on it.
This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.