6 ms·

Should we remove XSLT from the web platform?

73 points by edent 1y ago

kixiQu 1y ago
https://maya.land/blogroll.opml https://maya.land/blogroll.opml My blogroll's better-known than my actual site, and it's feed-reader compatible OPML that I've just made fun with additional attributes and XSLT. A server-side transform to vend duplicate OPML and HTML would be a bummer. I'm not an Important Web Platform user or anything, but I wish more people would share their feed-reader exports – and I've thought about trying to share tooling to extend/display them like this. It'll be sad if that ends up impossible.
JimDabell 1y ago
Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
- omgtehlion 1y ago
  > so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.
  - conductr 1y ago
    When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required
    - 3036e4 1y ago
      Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability. I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.
      - shiomiru 1y ago
        > Things can remain backwards compatible forever. This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. Indeed, to me it seems that at some point, you either have to a) freeze the standard b) drop old stuff c) accept that there is no standard and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate. (Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)
        account42 1y ago
        > This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that. Google is not proposing to reign in that behavior. > a) freeze the standard Yes, or rather new features should become rarer over time. > and with the web as a whole, we are firmly headed towards option c) Which has nothing to do with backwards compatibility but with Chromes appetite for adding new APIs, presumably with exactly this outcome being their goal.
  - pjmlp 1y ago
    Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU. How great that five years later WebGPU is something we can rely on in portable way. /s
- bawolff 1y ago
  The wikipedia api has an option where you can add an xslt stylesheet to its output. When i was young and stupid and learning to program i made an xslt stylesheet to extract dictionary definitions from the api. It was meant to be combined with a bookmarklet that when you double clicked a word opened it in an iframe. It was terrible, but i was so proud of it at the time. It seems like it stopped working at some point, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&xslt=MediaWiki%3AextractFirst.xsl&prop=text&page=word&lang=en&count=1&showWord=none&audio=none&redirects=on https://en.wiktionary.org/w/api.php?action=parse&format=xml&... Sorry if this is too off topic, it just triggered some memories
  - toyg 1y ago
    > It was terrible, but i was so proud of it at the time. Terrible why? Bookmarklets and XSLT (and things like Greasemonkey userscripts) were some of the things that made the web more "read-write" in the '00s: anyone could remix web content however they saw fit, optimizing it for their personal use-cases, and often attracted kids and "normies" to coding. Even today, they can be used to do stuff that most people find magical. Unfortunately they are unfashionable, so they're slowly getting strangled by the big players who want to have all the control all the time.
    - bawolff 1y ago
      Sadly i just filed a bug to remove the xslt option from mediawiki's api. By terrible i just mean the code was really hacky. I was a newbie and exploring.
- cousin_it 1y ago
  Maybe off topic, but I was really inspired by this article and started thinking about other ways to have "in-browser templating". And then realized that the old function document.write() is actually very convenient for this. Tried to write up the pros and cons here: https://vladimirslepnev.me/write https://vladimirslepnev.me/write Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/write https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...
miki_oomiri 1y ago
The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions. I see it hasn't changed.
- myaccountonhn 1y ago
  It sucks, people just doing their job should be treated with respect. That said I can also feel like the technocratic decision making process make it so some people aren't given any voice nor choice. Its whatever the US tech giants want that decides for the rest of us.
- edent 1y ago
  Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing. This change would make people sad because things they like would stop working. It would cause them stress because they would have to work hard to fix or replace things. It would cause them anger because some unaccountable people would be making decisions without considering them. It would make them afraid that those same people might destroy something else which is useful. These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback. Web developers aren't Vulcans. We have and use emotions.
  - perching_aix 1y ago
    > Web developers aren't Vulcans. We have and use emotions. You might find that the people on their end, too, have and use emotions. Acknowledging and voicing your emotional and mental position is one thing, that alone doesn't make it overly emotional. What does is being so taken by them, that it ends up trampling on others'.
  - haburka 1y ago
    It’s ok to have emotions, even as an adult, we all have feelings. However, it’s important to be kind to other humans and to treat humans with respect. Even on the internet, even when people are proposing removing features from a browser. Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have. I think this is especially true on GitHub where people are using their real professional identities. I’m honestly shocked that anyone can just comment on these proposals given how toxic it gets. Imagine if this is your day to day work environment - you’re trying to improve the web, which is already a tremendously difficult thing while all of these keyboard warriors are insulting you and your efforts. I wouldn’t want to wish that on anyone.
user____name 1y ago
The problem with browsers is that they rely on other standards. If a browser needs to maintain backward compatibility and requires an evolving standard that ALSO requires backward compatibility, this acts like a multiplier on implementation complexity. This also means it becomes increasingly difficult to spin up a new browser engine, and the fewer of those there are, the easier it is for the big ones to just add what they want and have it become a standard, reinforcing the issue.
- ethan_smith 1y ago
  XSLT adds ~100k lines of specialized code to browser engines with near-zero telemetry usage (<0.01% of page loads), making it a prime example of the maintenance burden vs. utility problem you're describing.
  - geocar 1y ago
    > near-zero telemetry usage (<0.01% of page loads), Perhaps without realising it, you are still describing numbers in the hundreds of millions perhaps billions, which isn't even close to zero when you're talking about atoms: Google does 200$ billion USD in annual ad revenue: At even a mere $1 CPM that's 200 trillion impressions a year. They put 5 ads on every page and we're at 40 trillion page loads a year that Google knows about. You tell me that even 0.001% of that is XML/XSLT and we're still talking hundreds of millions of page loads every year. And that's just the ones Google knows about: Pages without Google ads like say https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... should definitely not be included in that telemetry at all, indicating the value should be much higher
bawolff 1y ago
I always kind of liked XSLT but it clearly has not caught on.
- hereonout2 1y ago
  I used it everyday for the first 5 years of my career, got my first big job off the back of a shorter graduate job that exposed me to it. It will always have a special heart too. However, in the way it was used in my roles at least - I found it enforced far too rigid a separation between the data and the presentation. There were multiple times a backend could not perform some function or transformation of the data, for various and always non technical reasons. That left it to the xslt developers to figure out a solution, and sometimes due to the limits of the language that involved writing a custom java function / xslt plugin. Things that were incredibly simple when some sort of scripting language is available in your frontend web app could be incredibly convoluted when all you had was an xslt processor.
- msgodel 1y ago
  I think most people just aren't aware its available in the browser.
- dev0001 1y ago
  Would you say the same about CSS if browsers only supported version 1.0 while it was being used in many other contexts and version 4.0 was being worked on?
deleted 1y ago
[deleted]
ChrisMarshallNY 1y ago
Obligatory xkcd: https://xkcd.com/1172/ https://xkcd.com/1172/
- toyg 1y ago
  I love XKCD, but this particular strip has been used to justify all sorts of arbitrary and negative decisions. XSLT support is not a bug.
  - ChrisMarshallNY 1y ago
    Same could be said for many other strips. It’s always about balance. I think I read, somewhere, that Microsoft actually reintroduced bugs into their OS, because so many people depended on workarounds and the buggy behavior.
globular-toast 1y ago
Isn't it a shame that we can only have one program installed on our computers. Imagine (if you can!) being able to have two programs, one (program A) that supports JS and all that shite, and another (program B) that supports XSLT and all that shite. If you're still with me imagine that program A could just call program B when it detects stuff that it doesn't support and vice versa. I know, I know, a measly 16 core CPU with 32Gi of memory is not going to be capable of such feats, but one can dream...
- johannes1234321 1y ago
  And how does a "web" work, which links "Hoyertext" between those places using XSLT and those which don't? And well, the browser tries to be the only program one uses, where all applications run inside it.
cess11 1y ago
I'd consider JS and WASM quite a bit more risky from a security standpoint, which is why everyone should refuse loading and executing those by default. Securing an XSLT 3.0 implementation would be much easier.
deleted 1y ago
[deleted]
Kwpolska 1y ago
Why is it always Google employees that want to kill things?
- Dlanv 1y ago
  It's more interesting and controversial to hear about
pdw 1y ago
It's disheartening that this Chrome dev in the comments shows himself to be completely unaware of the RSS ecosystem...
- Avamander 1y ago
  I still can't see how browser support is useful for that. Now to think of it, I'd like to see one useful example of its usage. Haven't seen one in a long long time.
  - JimDabell 1y ago
    Take a look at this feed: https://interconnected.org/home/feed https://interconnected.org/home/feed You’ll see if you view source that it’s an RSS (XML) file that your browser doesn’t know how to render. But at the top, there is this: <?xml-stylesheet href="/home/static/styles/pretty-feed-v3.xsl" type="text/xsl"?> Your browser loads that XSLT and uses it to transcode the XML into HTML, which your browser can now render. The source is here: https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-feed-v3.xsl https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-...
    - Avamander 1y ago
      Thank you for that example, it does help understand how it could be useful. Though I'm still unsure if supporting that use-case indefinitely is worth the long-term effort. In the same way that FTP support was dropped.
- bawolff 1y ago
  Quite frankly i think if browsers had better default display of RSS then it wouldnt really matter.
ahofmann 1y ago
That polyfill is 46 Megabytes in size. This would suck so much to have this suddenly in the build.
account42 1y ago
How is the answer to any question "Should we remove X from the web platform?" where X wasn't introduced in the last week an has actual users not a resounding "No, WTF is wrong with you.".
- NoGravitas 1y ago
  That was the actual answer, but those comments got hidden and the discussion locked.
- bitwize 1y ago
  Easy. Just use the GNOME argument: round a small enough minority down to "nobody" and then confidently claim "nobody actually uses that, and we don't want to maintain it, so we're removing it."
  - naniwaduni 1y ago
    In order to reach that point faster, never improve the feature and make it increasingly cumbersome to use to turn potential users off it.
    - chrismorgan 1y ago
      And that has definitely happened with XSLT. Ancient version, incomplete feature support and behaviour, terrible debugging experience…
- Avamander 1y ago
  Because not everything should be kept in browsers for all eternity? Thankfully it isn't like that and things do get removed.
  - account42 1y ago
    They absolutely should and this should be considered when adding new features. That's called having a stable platform that others can build upon.
llimos 1y ago
Even skechers.com doesn't use it any more [1] [1] https://thedailywtf.com/articles/Sketchy-Skecherscom https://thedailywtf.com/articles/Sketchy-Skecherscom
ricardolopes 1y ago
This could be debatable if browsers had any UI at all to display XML. It's incomprehensible that if you open the open web solution for subscribing to web content (RSS) you're greeted with a wall of unformatted text. Right now, XSLT is the poor fix to that browser's basic inability.
- account42 1y ago
  Firefox at least did have a sensible default style sheet for RSS at some point.
mbrock 1y ago
Can't they make a memory safe XSLTProcessor by just compiling libxml to WebAssembly?
chrismorgan 1y ago
I am reminded of when Google attempted to kill MathML a few years ago because it was complexity and no one was using it (… because Chromium didn’t support it—all others did). There was widespread rebellion, and it actually led to Igalia implementing it and Google accepting and shipping it. It wouldn’t surprise me to see a resurgence of interest in XSLT after this, if only for formatting Atom/RSS feeds. (BTW, prefer Atom unless you’re operating in podcasting, it’s far more sane in ways that occasionally actually matter, and everything supports it except in podcasting which Apple ruined. If you want a featureful stylesheet to look at for reference, mine is the best I know of: https://chrismorgan.info/atom.xsl https://chrismorgan.info/atom.xsl, https://temp.chrismorgan.info/2022-05-10-rss.xsl https://temp.chrismorgan.info/2022-05-10-rss.xsl.)
- 07cwu9 1y ago
  I'd like to genuinely ask: what's the benefit of providing a visually appealing feed? I thought feeds were meant for programs. Do you/people directly browse individual feeds? Nice feed look BTW!
  - JimDabell 1y ago
    Some people aren’t familiar with auto discovery or feeds in general, so it’s desirable to have a link in your navigation that goes to your feed. When people click that link, they should see something useful and not just markup or a download prompt.
  - dev0001 1y ago
    Most of the time you wouldn't even notice that a web page is the result of a client-side XSLT transformation, for example: https://xmpp.org/extensions/xep-0182.xml https://xmpp.org/extensions/xep-0182.xml
dev0001 1y ago
From the GitHub thread (https://github.com/whatwg/html/issues/11523#issuecomment-3156664555 https://github.com/whatwg/html/issues/11523#issuecomment-315...) > I don't think there's a strong "Open Web" argument to be made here. XML data files being able to be reformatted into HTML is somewhat of an accident of history; we don't have similar functionality for any other data type, despite, for example, JSON files being vastly more common on the web than XML. Ironically, we would have support for transforming JSON if XSLT in the browser had been kept up-to-date. Interestingly, "XML data files being able to be reformatted into HTML" was a deliberate choice to support and encourage the separation of content and presentation. CSS was introduced for the same reason but to address a slightly different (but complimentary) aspect of the same ambition and it's flourished. Imagine how widely CSS would be being used if browser support was still stuck at CSS 1.0.
bryanrasmussen 1y ago
I tried to comment on this just now but I was blocked as the thread has been limited to collaborators, their word not mine, but wow. So I guess I'll put it here assuming someone reads. Given the various comments people have about the dependencies on XSLT that various standards, applications and workflows have. I believe that the default display of XML documents in Chrome, Firefox, and I suppose Edge is handled by an XSLT. It used to be that MSXML shipped with an XSLT (and even earlier a wd-xsl document) as a resource that was used to style any XML document for display if the XML document did not have an associated stylesheet when you opened it in IE or other views that used IE for rendering. I believe this same thing is done by the browsers mentioned, or at least it used to be https://stackoverflow.com/questions/9463402/default-xml-stylesheet-in-chrome https://stackoverflow.com/questions/9463402/default-xml-styl... which is why when you open an XML document without styling information in those documents it is represented as a tree view with expandable collapsible nodes. I suppose they will just implement a default rendering for XML using some other code rather than running an XSLT upon it, but this applies as well as all these edge cases of handling RSS feeds etc. Safari does not have a stylesheet rendering for unstyled XML which is why it just shows the text nodes of the document and nothing else.
dev0001 1y ago
U.S. legislation is delivered on the web as XSLT-styled XML and depends on web browsers continuing to provide native support for client-side XSLT. Examples: https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BILLS-119hr400ih.xml https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...
yawaramin 1y ago
So the libxml/libxslt unpaid volunteer maintainer wants to stop doing 'disclosure embargo' of reported security issues: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 Shortly after that, Google Chrome want to remove XSLT support. Coincidence?

73 points by edent 1y ago

https://maya.land/blogroll.opml https://maya.land/blogroll.opml My blogroll's better-known than my actual site, and it's feed-reader compatible OPML that I've just made fun with additional attributes and XSLT. A server-side transform to vend duplicate OPML and HTML would be a bummer. I'm not an Important Web Platform user or anything, but I wish more people would share their feed-reader exports – and I've thought about trying to share tooling to extend/display them like this. It'll be sad if that ends up impossible.

JimDabell 1y ago

Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.

omgtehlion 1y ago
> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.
- conductr 1y ago
  When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required
  - 3036e4 1y ago
    Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability. I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.
    - shiomiru 1y ago
      > Things can remain backwards compatible forever. This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. Indeed, to me it seems that at some point, you either have to a) freeze the standard b) drop old stuff c) accept that there is no standard and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate. (Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)
      - account42 1y ago
        > This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that. Google is not proposing to reign in that behavior. > a) freeze the standard Yes, or rather new features should become rarer over time. > and with the web as a whole, we are firmly headed towards option c) Which has nothing to do with backwards compatibility but with Chromes appetite for adding new APIs, presumably with exactly this outcome being their goal.
- pjmlp 1y ago
  Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU. How great that five years later WebGPU is something we can rely on in portable way. /s
bawolff 1y ago
The wikipedia api has an option where you can add an xslt stylesheet to its output. When i was young and stupid and learning to program i made an xslt stylesheet to extract dictionary definitions from the api. It was meant to be combined with a bookmarklet that when you double clicked a word opened it in an iframe. It was terrible, but i was so proud of it at the time. It seems like it stopped working at some point, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&xslt=MediaWiki%3AextractFirst.xsl&prop=text&page=word&lang=en&count=1&showWord=none&audio=none&redirects=on https://en.wiktionary.org/w/api.php?action=parse&format=xml&... Sorry if this is too off topic, it just triggered some memories
- toyg 1y ago
  > It was terrible, but i was so proud of it at the time. Terrible why? Bookmarklets and XSLT (and things like Greasemonkey userscripts) were some of the things that made the web more "read-write" in the '00s: anyone could remix web content however they saw fit, optimizing it for their personal use-cases, and often attracted kids and "normies" to coding. Even today, they can be used to do stuff that most people find magical. Unfortunately they are unfashionable, so they're slowly getting strangled by the big players who want to have all the control all the time.
  - bawolff 1y ago
    Sadly i just filed a bug to remove the xslt option from mediawiki's api. By terrible i just mean the code was really hacky. I was a newbie and exploring.
cousin_it 1y ago
Maybe off topic, but I was really inspired by this article and started thinking about other ways to have "in-browser templating". And then realized that the old function document.write() is actually very convenient for this. Tried to write up the pros and cons here: https://vladimirslepnev.me/write https://vladimirslepnev.me/write Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/write https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...

miki_oomiri 1y ago

The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions. I see it hasn't changed.

myaccountonhn 1y ago
It sucks, people just doing their job should be treated with respect. That said I can also feel like the technocratic decision making process make it so some people aren't given any voice nor choice. Its whatever the US tech giants want that decides for the rest of us.
edent 1y ago
Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing. This change would make people sad because things they like would stop working. It would cause them stress because they would have to work hard to fix or replace things. It would cause them anger because some unaccountable people would be making decisions without considering them. It would make them afraid that those same people might destroy something else which is useful. These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback. Web developers aren't Vulcans. We have and use emotions.
- perching_aix 1y ago
  > Web developers aren't Vulcans. We have and use emotions. You might find that the people on their end, too, have and use emotions. Acknowledging and voicing your emotional and mental position is one thing, that alone doesn't make it overly emotional. What does is being so taken by them, that it ends up trampling on others'.
- haburka 1y ago
  It’s ok to have emotions, even as an adult, we all have feelings. However, it’s important to be kind to other humans and to treat humans with respect. Even on the internet, even when people are proposing removing features from a browser. Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have. I think this is especially true on GitHub where people are using their real professional identities. I’m honestly shocked that anyone can just comment on these proposals given how toxic it gets. Imagine if this is your day to day work environment - you’re trying to improve the web, which is already a tremendously difficult thing while all of these keyboard warriors are insulting you and your efforts. I wouldn’t want to wish that on anyone.

user____name 1y ago

The problem with browsers is that they rely on other standards. If a browser needs to maintain backward compatibility and requires an evolving standard that ALSO requires backward compatibility, this acts like a multiplier on implementation complexity. This also means it becomes increasingly difficult to spin up a new browser engine, and the fewer of those there are, the easier it is for the big ones to just add what they want and have it become a standard, reinforcing the issue.

ethan_smith 1y ago
XSLT adds ~100k lines of specialized code to browser engines with near-zero telemetry usage (<0.01% of page loads), making it a prime example of the maintenance burden vs. utility problem you're describing.
- geocar 1y ago
  > near-zero telemetry usage (<0.01% of page loads), Perhaps without realising it, you are still describing numbers in the hundreds of millions perhaps billions, which isn't even close to zero when you're talking about atoms: Google does 200$ billion USD in annual ad revenue: At even a mere $1 CPM that's 200 trillion impressions a year. They put 5 ads on every page and we're at 40 trillion page loads a year that Google knows about. You tell me that even 0.001% of that is XML/XSLT and we're still talking hundreds of millions of page loads every year. And that's just the ones Google knows about: Pages without Google ads like say https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... should definitely not be included in that telemetry at all, indicating the value should be much higher

bawolff 1y ago

I always kind of liked XSLT but it clearly has not caught on.

hereonout2 1y ago
I used it everyday for the first 5 years of my career, got my first big job off the back of a shorter graduate job that exposed me to it. It will always have a special heart too. However, in the way it was used in my roles at least - I found it enforced far too rigid a separation between the data and the presentation. There were multiple times a backend could not perform some function or transformation of the data, for various and always non technical reasons. That left it to the xslt developers to figure out a solution, and sometimes due to the limits of the language that involved writing a custom java function / xslt plugin. Things that were incredibly simple when some sort of scripting language is available in your frontend web app could be incredibly convoluted when all you had was an xslt processor.
msgodel 1y ago
I think most people just aren't aware its available in the browser.
dev0001 1y ago
Would you say the same about CSS if browsers only supported version 1.0 while it was being used in many other contexts and version 4.0 was being worked on?

deleted 1y ago

[deleted]

ChrisMarshallNY 1y ago

Obligatory xkcd: https://xkcd.com/1172/ https://xkcd.com/1172/

toyg 1y ago
I love XKCD, but this particular strip has been used to justify all sorts of arbitrary and negative decisions. XSLT support is not a bug.
- ChrisMarshallNY 1y ago
  Same could be said for many other strips. It’s always about balance. I think I read, somewhere, that Microsoft actually reintroduced bugs into their OS, because so many people depended on workarounds and the buggy behavior.

globular-toast 1y ago

Isn't it a shame that we can only have one program installed on our computers. Imagine (if you can!) being able to have two programs, one (program A) that supports JS and all that shite, and another (program B) that supports XSLT and all that shite. If you're still with me imagine that program A could just call program B when it detects stuff that it doesn't support and vice versa. I know, I know, a measly 16 core CPU with 32Gi of memory is not going to be capable of such feats, but one can dream...

johannes1234321 1y ago
And how does a "web" work, which links "Hoyertext" between those places using XSLT and those which don't? And well, the browser tries to be the only program one uses, where all applications run inside it.

cess11 1y ago

I'd consider JS and WASM quite a bit more risky from a security standpoint, which is why everyone should refuse loading and executing those by default. Securing an XSLT 3.0 implementation would be much easier.

deleted 1y ago

[deleted]

Kwpolska 1y ago

Why is it always Google employees that want to kill things?

Dlanv 1y ago
It's more interesting and controversial to hear about

pdw 1y ago

It's disheartening that this Chrome dev in the comments shows himself to be completely unaware of the RSS ecosystem...

Avamander 1y ago
I still can't see how browser support is useful for that. Now to think of it, I'd like to see one useful example of its usage. Haven't seen one in a long long time.
- JimDabell 1y ago
  Take a look at this feed: https://interconnected.org/home/feed https://interconnected.org/home/feed You’ll see if you view source that it’s an RSS (XML) file that your browser doesn’t know how to render. But at the top, there is this: <?xml-stylesheet href="/home/static/styles/pretty-feed-v3.xsl" type="text/xsl"?> Your browser loads that XSLT and uses it to transcode the XML into HTML, which your browser can now render. The source is here: https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-feed-v3.xsl https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-...
  - Avamander 1y ago
    Thank you for that example, it does help understand how it could be useful. Though I'm still unsure if supporting that use-case indefinitely is worth the long-term effort. In the same way that FTP support was dropped.
bawolff 1y ago
Quite frankly i think if browsers had better default display of RSS then it wouldnt really matter.

ahofmann 1y ago

That polyfill is 46 Megabytes in size. This would suck so much to have this suddenly in the build.

account42 1y ago

How is the answer to any question "Should we remove X from the web platform?" where X wasn't introduced in the last week an has actual users not a resounding "No, WTF is wrong with you.".

NoGravitas 1y ago
That was the actual answer, but those comments got hidden and the discussion locked.
bitwize 1y ago
Easy. Just use the GNOME argument: round a small enough minority down to "nobody" and then confidently claim "nobody actually uses that, and we don't want to maintain it, so we're removing it."
- naniwaduni 1y ago
  In order to reach that point faster, never improve the feature and make it increasingly cumbersome to use to turn potential users off it.
  - chrismorgan 1y ago
    And that has definitely happened with XSLT. Ancient version, incomplete feature support and behaviour, terrible debugging experience…
Avamander 1y ago
Because not everything should be kept in browsers for all eternity? Thankfully it isn't like that and things do get removed.
- account42 1y ago
  They absolutely should and this should be considered when adding new features. That's called having a stable platform that others can build upon.

llimos 1y ago

Even skechers.com doesn't use it any more [1] [1] https://thedailywtf.com/articles/Sketchy-Skecherscom https://thedailywtf.com/articles/Sketchy-Skecherscom

ricardolopes 1y ago

This could be debatable if browsers had any UI at all to display XML. It's incomprehensible that if you open the open web solution for subscribing to web content (RSS) you're greeted with a wall of unformatted text. Right now, XSLT is the poor fix to that browser's basic inability.

account42 1y ago
Firefox at least did have a sensible default style sheet for RSS at some point.

mbrock 1y ago

Can't they make a memory safe XSLTProcessor by just compiling libxml to WebAssembly?

chrismorgan 1y ago

I am reminded of when Google attempted to kill MathML a few years ago because it was complexity and no one was using it (… because Chromium didn’t support it—all others did). There was widespread rebellion, and it actually led to Igalia implementing it and Google accepting and shipping it. It wouldn’t surprise me to see a resurgence of interest in XSLT after this, if only for formatting Atom/RSS feeds. (BTW, prefer Atom unless you’re operating in podcasting, it’s far more sane in ways that occasionally actually matter, and everything supports it except in podcasting which Apple ruined. If you want a featureful stylesheet to look at for reference, mine is the best I know of: https://chrismorgan.info/atom.xsl https://chrismorgan.info/atom.xsl, https://temp.chrismorgan.info/2022-05-10-rss.xsl https://temp.chrismorgan.info/2022-05-10-rss.xsl.)

07cwu9 1y ago
I'd like to genuinely ask: what's the benefit of providing a visually appealing feed? I thought feeds were meant for programs. Do you/people directly browse individual feeds? Nice feed look BTW!
- JimDabell 1y ago
  Some people aren’t familiar with auto discovery or feeds in general, so it’s desirable to have a link in your navigation that goes to your feed. When people click that link, they should see something useful and not just markup or a download prompt.
- dev0001 1y ago
  Most of the time you wouldn't even notice that a web page is the result of a client-side XSLT transformation, for example: https://xmpp.org/extensions/xep-0182.xml https://xmpp.org/extensions/xep-0182.xml

dev0001 1y ago

From the GitHub thread (https://github.com/whatwg/html/issues/11523#issuecomment-3156664555 https://github.com/whatwg/html/issues/11523#issuecomment-315...) > I don't think there's a strong "Open Web" argument to be made here. XML data files being able to be reformatted into HTML is somewhat of an accident of history; we don't have similar functionality for any other data type, despite, for example, JSON files being vastly more common on the web than XML. Ironically, we would have support for transforming JSON if XSLT in the browser had been kept up-to-date. Interestingly, "XML data files being able to be reformatted into HTML" was a deliberate choice to support and encourage the separation of content and presentation. CSS was introduced for the same reason but to address a slightly different (but complimentary) aspect of the same ambition and it's flourished. Imagine how widely CSS would be being used if browser support was still stuck at CSS 1.0.

bryanrasmussen 1y ago

I tried to comment on this just now but I was blocked as the thread has been limited to collaborators, their word not mine, but wow. So I guess I'll put it here assuming someone reads. Given the various comments people have about the dependencies on XSLT that various standards, applications and workflows have. I believe that the default display of XML documents in Chrome, Firefox, and I suppose Edge is handled by an XSLT. It used to be that MSXML shipped with an XSLT (and even earlier a wd-xsl document) as a resource that was used to style any XML document for display if the XML document did not have an associated stylesheet when you opened it in IE or other views that used IE for rendering. I believe this same thing is done by the browsers mentioned, or at least it used to be https://stackoverflow.com/questions/9463402/default-xml-stylesheet-in-chrome https://stackoverflow.com/questions/9463402/default-xml-styl... which is why when you open an XML document without styling information in those documents it is represented as a tree view with expandable collapsible nodes. I suppose they will just implement a default rendering for XML using some other code rather than running an XSLT upon it, but this applies as well as all these edge cases of handling RSS feeds etc. Safari does not have a stylesheet rendering for unstyled XML which is why it just shows the text nodes of the document and nothing else.

dev0001 1y ago

U.S. legislation is delivered on the web as XSLT-styled XML and depends on web browsers continuing to provide native support for client-side XSLT. Examples: https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BILLS-119hr400ih.xml https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...

yawaramin 1y ago

So the libxml/libxslt unpaid volunteer maintainer wants to stop doing 'disclosure embargo' of reported security issues: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 Shortly after that, Google Chrome want to remove XSLT support. Coincidence?