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.
In 19th century Russia there was a thinker, N. F. Fedorov, who wanted to revive all dead people. He saw it as the ultimate goal of humanity. (He worked in a library, a very telling occupation. He spent most of what he earned to support others.) We do not know how to revive dead people or if we can do that at all; but we certainly can revive old tech or just not let it die.
Of course, this job is not for everyone. We cannot count on the richest, apparently, they're too busy getting richer. This is a job for monks.
chrismorgan 1 hours ago [-]
Presuming this goes ahead, I believe this is the first time a standard, baseline-available feature will be removed.
There have been other removals, but few of them were of even specified features, and I don’t think any of them have been universally available. One of the closest might be showModalDialog <https://web.archive.org/web/20140401014356/http://dev.opera....>, but I gather mobile browsers never supported it anyway, and it was a really problematic feature from an implementation perspective too. You could argue Mutation Events from ~2011 qualifies¹; it was supplanted by Mutation Observers within two years, yet hung around for over a decade before being removed. As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.
And so here they are now planning to remove a well-entrenched (if not especially commonly used) feature against the clearly-expressed will of the actual developers, in a one year time frame.
—⁂—
¹ I choose to disqualify Mutation Events because no one ever finished their implementation: WebKit heritage never did DOMAttrModified, Gecko/Trident heritage never did DOMNodeInsertedIntoDocument or DOMNodeRemovedFromDocument. Flimsy excuse, probably. If you want to count it, perhaps you’ll agree to consider XSLT the first time a major, standard, baseline-available feature will be removed?
bawolff 3 minutes ago [-]
> 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.
veeti 36 minutes ago [-]
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.
echelon 13 minutes ago [-]
> maintaining anything to do with XML or XSLT either.
These aren't horrible formats or standards. XSLT is actually somewhat elegant.
hannob 1 minutes ago [-]
Counterpoint: XML is a horrible format.
Why? Answer this question: how can you use XML in a way that does not create horrible security vulnerabilities?
I know the answer, but it is extremely nontrivial, and highly dependent on which programming language, library, and sometimes even which library function you use. The fact that there's no easy way to use XML without creating a security footgun is reason enough to avoid it.
CamJN 53 minutes ago [-]
Maybe the blink or marquee tags? I’m pretty sure those don’t work anymore...
chrismorgan 40 minutes ago [-]
<marquee> still works fine. Better than it used to, honestly, as at least Firefox and Chromium removed the deliberate low frame rate at some point in the last decade.
<blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>.
> Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996.
Fun times. Both essentially accusing the other of having a dumb tag.
bojle 34 minutes ago [-]
marquee is used religiously by some official Indian websites [1]. It's the primary mechanism they use to deliver news or updates on the websites.
Extremely popular in Indian government websites, often implemented with <marquee>, but also often implemented by a different mechanism so that it can stop scrolling on mouseover.
Indian Rail <https://www.indianrail.gov.in/> has one containing the chart from a mid-2024 train accident, an invitation to contribute a recording of the national anthem from 2021, and a link to parcel booking. Oh, and “NEW!” animated GIFs between the three items.
cassonmars 1 hours ago [-]
XSLT is great, but its core problem is that the tooling is awful. And a lot of this has to do with the primary author of the XSLT specification, keeping a proprietary (and expensive) library as the main library that implements the ungodly terse spec. Simpler standards and open tooling won out, not just because it was simpler, but because there wasn't someone chiefly in charge of the spec essentially making the tooling an enterprise sales funnel. A shame.
I want browsers to be minimal and simple. For example, canvas should only provide a framebuffer to draw into, and all the rest can be done with WASM libraries. Web Audio should only provide an audio thread, and things like low-pass filters can be implemented in WASM. WebRTC should only provide UDP support, etc.
This would make creating competition easier and reduce attack surface. As a nice side effect, it would become impossible to use canvas or web audio for fingerprinting.
icameron 35 minutes ago [-]
During my college undergrad CS series we had a practicum with a real engineer from HP or somewhere. Our project was to help the world find and download printer drivers over the web. The project was to make a Java web service send XML that conformed to a schema, which would be turned into a webpage by a transform aka XSLT. It seemed convoluted at the time. The teacher showed us “the how” but I guess “the why” was left as an exercise for the reader. I never understood the big picture- at the time it seemed rather complex. But now I realize this probably would have scaled quite well on turn of the century hardware.
postepowanieadm 34 minutes ago [-]
In Europe some countries still use XML as the official data format and XSLT as the official code format.
Animats 54 minutes ago [-]
It would be kind of nice if HTML had something where you can make a remote fetch request for JSON or XML data and get it formatted in some CSS-defined way, without Javascript.
bawolff 23 seconds ago [-]
They are only getting rid of xslt. You can still use <?xml-stylesheet with CSS
apimade 8 minutes ago [-]
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.
29athrowaway 2 hours ago [-]
XSLT is amazing.
Kimitri 4 minutes ago [-]
It really is. It's extremely handy albeit a bit niche these days.
imiric 1 hours ago [-]
So, instead of a giant corporation with all the resources in the world stepping in and maintaining a core web library, they're deciding to remove a feature because the lone maintainer who has been doing a thankless job for years took a 6 month break, and has decided to unsurprisingly step down from this role.
I suppose we can expect support for XML to be dropped soon as well, since libxml2 maintenance is ending this year.
I don't buy the excuse of low number of users. Google's AMP has abysmal usage numbers, yet they're still maintaining that garbage.
Google has been a net negative for the web, and directly responsible for the shit show it is today. An entirely expected outcome considering it is steered by corporate interests.
ozim 8 minutes ago [-]
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.
bugbuddy 2 hours ago [-]
Good riddance. The web needs to shed all the old baggages like this to move forward. Looking forward to MCP becoming part of the browser.
imiric 2 hours ago [-]
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.
Rendered at 07:25:30 GMT+0000 (Coordinated Universal Time) with Vercel.
In 19th century Russia there was a thinker, N. F. Fedorov, who wanted to revive all dead people. He saw it as the ultimate goal of humanity. (He worked in a library, a very telling occupation. He spent most of what he earned to support others.) We do not know how to revive dead people or if we can do that at all; but we certainly can revive old tech or just not let it die.
Of course, this job is not for everyone. We cannot count on the richest, apparently, they're too busy getting richer. This is a job for monks.
There have been other removals, but few of them were of even specified features, and I don’t think any of them have been universally available. One of the closest might be showModalDialog <https://web.archive.org/web/20140401014356/http://dev.opera....>, but I gather mobile browsers never supported it anyway, and it was a really problematic feature from an implementation perspective too. You could argue Mutation Events from ~2011 qualifies¹; it was supplanted by Mutation Observers within two years, yet hung around for over a decade before being removed. As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway.
And so here they are now planning to remove a well-entrenched (if not especially commonly used) feature against the clearly-expressed will of the actual developers, in a one year time frame.
—⁂—
¹ I choose to disqualify Mutation Events because no one ever finished their implementation: WebKit heritage never did DOMAttrModified, Gecko/Trident heritage never did DOMNodeInsertedIntoDocument or DOMNodeRemovedFromDocument. Flimsy excuse, probably. If you want to count it, perhaps you’ll agree to consider XSLT the first time a major, standard, baseline-available feature will be removed?
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.
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.
These aren't horrible formats or standards. XSLT is actually somewhat elegant.
Why? Answer this question: how can you use XML in a way that does not create horrible security vulnerabilities?
I know the answer, but it is extremely nontrivial, and highly dependent on which programming language, library, and sometimes even which library function you use. The fact that there's no easy way to use XML without creating a security footgun is reason enough to avoid it.
<blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>.
> Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996.
Fun times. Both essentially accusing the other of having a dumb tag.
[1] For example: https://www.nagpuruniversity.ac.in/
Indian Rail <https://www.indianrail.gov.in/> has one containing the chart from a mid-2024 train accident, an invitation to contribute a recording of the national anthem from 2021, and a link to parcel booking. Oh, and “NEW!” animated GIFs between the three items.
This would make creating competition easier and reduce attack surface. As a nice side effect, it would become impossible to use canvas or web audio for fingerprinting.
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.
I suppose we can expect support for XML to be dropped soon as well, since libxml2 maintenance is ending this year.
I don't buy the excuse of low number of users. Google's AMP has abysmal usage numbers, yet they're still maintaining that garbage.
Google has been a net negative for the web, and directly responsible for the shit show it is today. An entirely expected outcome considering it is steered by corporate interests.
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.
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.