Should we remove XSLT from the web platform?(github.com)
github.com
Should we remove XSLT from the web platform?
https://github.com/whatwg/html/issues/11523
98 comments
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!
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
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.
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.... https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...
https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...
From the GitHub thread (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.
> 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.
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
Shortly after that, Google Chrome want to remove XSLT support.
Coincidence?
Shortly after that, Google Chrome want to remove XSLT support.
Coincidence?
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.
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.
Personally I've found googles responses to be very rude; they've asked for feedback and people have come back saying "We're still using this, please don't just remove it" and despite that they seem to be completely uncompromising on removing it without any adjustments like shipping the wasm polyfill instead of native code.
It kind of baffles me that they could even consider this, maybe I'm just naiive but the webs greatest strength has always been it's backwards compatibility; I can fire a page up written 30 years ago and it still renders (assuming it wasn't built in flash lol). Breaking the user experience like this and saying "well the owners need to update their site" doesn't work - a lot of these pages won't be actively maintained or under the control of someone who can make changes.
It kind of baffles me that they could even consider this, maybe I'm just naiive but the webs greatest strength has always been it's backwards compatibility; I can fire a page up written 30 years ago and it still renders (assuming it wasn't built in flash lol). Breaking the user experience like this and saying "well the owners need to update their site" doesn't work - a lot of these pages won't be actively maintained or under the control of someone who can make changes.
The unwillingness to ship the polyfill as a substitute for the native code really puts the lie to any notion that this is really about security/attack surface angle that some people have latched onto, too.
Hiding any negative comment is especially childish.
> the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…)
The vast majority of comments on https://github.com/whatwg/html/issues/11523 are polite and respectful.
Also, "Smaug, Anne, Emilo" did not "make the web happen." They have influenced how the web has developed, in particular favouring functionality and uses that are dependent on Javascript, and neglecting to ensure parity of opportunity for other approaches to flourish.
The vast majority of comments on https://github.com/whatwg/html/issues/11523 are polite and respectful.
Also, "Smaug, Anne, Emilo" did not "make the web happen." They have influenced how the web has developed, in particular favouring functionality and uses that are dependent on Javascript, and neglecting to ensure parity of opportunity for other approaches to flourish.
In my own personal experience on dealing with him, Anne is an arrogant douche who quite frankly hasn't been yelled at enough
A lot of the hate is actually justified (with the exception of hixxie)
A lot of the hate is actually justified (with the exception of hixxie)
Or you could try having more empathy and being less done deaf yourself.
Users don't like when you take functionality away from them. This is an appropriate response to a proposal to break part of the web just to make things a bit easier for browser developers (who are meanwhile adding a gazillion other things that are much more complex and actively hurt the users interests).
Users don't like when you take functionality away from them. This is an appropriate response to a proposal to break part of the web just to make things a bit easier for browser developers (who are meanwhile adding a gazillion other things that are much more complex and actively hurt the users interests).
As someone who is an open source dev (but not for anything this prominent).
Sometimes you have to remove features to make a product good. Its sad, but if your product includes the kitchen sink, its not a good product and drags everything down.
The users yell at me too sometimes.
Sometimes you have to remove features to make a product good. Its sad, but if your product includes the kitchen sink, its not a good product and drags everything down.
The users yell at me too sometimes.
The problem here is that the web is not Google's product but they are treating it as if were.
> 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 think if Gecko crashed less that'd be great.
I think if Gecko starts selling me a VPN service, and the parent org gets busy doing a bunch of real-estate investments, I wonder if you're making a web browser anymore.
> the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…)
I'm sorry I disagree.
I am hearing them say they can't make the web happen, because it's hard and they're not very good at programming, they put so many bugs in their code they just can't fix it, and it's really interfering with their efforts to add another privacy-impacting feature that they can use to sell more ads.
I think if every one of them got hit by a bus tomorrow absolutely nothing would change on the web except maybe we'd keep XSLT for another six months.
I want to appreciate anything you've done for Gecko, but it's hard if you don't realise it's people like me made the web happen too: I've been building web applications since 1994, and my applications have run on billions of devices at this point, and paid for my house, and some twenty years ago I used XSLT.
Do you really think I should bail them out by rewriting my fully working code so they don't have to fix their smelly broken code? You really think I have no standing to be a little bit annoyed by that attitude?
I think if Gecko crashed less that'd be great.
I think if Gecko starts selling me a VPN service, and the parent org gets busy doing a bunch of real-estate investments, I wonder if you're making a web browser anymore.
> the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…)
I'm sorry I disagree.
I am hearing them say they can't make the web happen, because it's hard and they're not very good at programming, they put so many bugs in their code they just can't fix it, and it's really interfering with their efforts to add another privacy-impacting feature that they can use to sell more ads.
I think if every one of them got hit by a bus tomorrow absolutely nothing would change on the web except maybe we'd keep XSLT for another six months.
I want to appreciate anything you've done for Gecko, but it's hard if you don't realise it's people like me made the web happen too: I've been building web applications since 1994, and my applications have run on billions of devices at this point, and paid for my house, and some twenty years ago I used XSLT.
Do you really think I should bail them out by rewriting my fully working code so they don't have to fix their smelly broken code? You really think I have no standing to be a little bit annoyed by that attitude?
This usually happens when a lot of people were forced to use a library or tool by their boss as part of a company mandate... They're already frustrated about not having a say about their tools and so when something goes wrong with the mandated tool/library, they just explode with rage.
I've participated in these two kinds of projects so I can see a clear difference in user behaviors.
Coerced users are particularly hateful, especially when the library or tool has serious flaws.
I've participated in these two kinds of projects so I can see a clear difference in user behaviors.
Coerced users are particularly hateful, especially when the library or tool has serious flaws.
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.
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.
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.
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.
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.
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.
> However, it’s important to be kind to other humans and to treat humans with respect.
Very true. But why is that argument never deployed against the bullies?
Chrome's developers say "We want to do X". People say "No, please don't." Chrome says "I'm not going to respect your wishes."
Where's the equality in that?
> Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have.
The same is also true of people making those proposals. Chrome devs should know (from bitter experience) that releasing a high-handed statement, studiously ignoring all dissent, and then swinging the ban-hammer is going to lead to ill-will.
Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
> I wouldn’t want to wish that on anyone.
I've been on the receiving end and - yes - it sucks. But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
Very true. But why is that argument never deployed against the bullies?
Chrome's developers say "We want to do X". People say "No, please don't." Chrome says "I'm not going to respect your wishes."
Where's the equality in that?
> Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have.
The same is also true of people making those proposals. Chrome devs should know (from bitter experience) that releasing a high-handed statement, studiously ignoring all dissent, and then swinging the ban-hammer is going to lead to ill-will.
Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
> I wouldn’t want to wish that on anyone.
I've been on the receiving end and - yes - it sucks. But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
> Where's the equality in that?
How would you expect equality in an arrangement where you have a few hundred to a few thousand very specific kind of people producing something for billions?
They are in a special position. Every time you depend on someone to do something for you you cannot perform yourself, either due to a time or any other constraint, that is no longer an equal relationship, and it cannot be. You can make it codependent at best, which is not the same, and doesn't apply here.
All the licensing and open collaboration theatrics are just that, "words on a piece of paper" and things that can go away. I feel people really misjudge the "power" they "gain" from "open" and "transparent" processes like this.
How would you expect equality in an arrangement where you have a few hundred to a few thousand very specific kind of people producing something for billions?
They are in a special position. Every time you depend on someone to do something for you you cannot perform yourself, either due to a time or any other constraint, that is no longer an equal relationship, and it cannot be. You can make it codependent at best, which is not the same, and doesn't apply here.
All the licensing and open collaboration theatrics are just that, "words on a piece of paper" and things that can go away. I feel people really misjudge the "power" they "gain" from "open" and "transparent" processes like this.
> They are in a special position.
And that position should not be that of a dictator.
And that position should not be that of a dictator.
> Chrome's developers say "We want to do X". People say "No, please don't." Chrome says "I'm not going to respect your wishes."
Absolutely not what's happening in that thread. Complete nonsense. It's a discussion/proposal.
The bullies are the people coming in and commenting with a bunch of rants, personal abuse, etc. Not the ones wanting to have a technical discussion (either pro or against removal). This is classic "reversing victim and offender" abuser/bully stuff.
Absolutely not what's happening in that thread. Complete nonsense. It's a discussion/proposal.
The bullies are the people coming in and commenting with a bunch of rants, personal abuse, etc. Not the ones wanting to have a technical discussion (either pro or against removal). This is classic "reversing victim and offender" abuser/bully stuff.
> Very true. But why is that argument never deployed against the bullies?
Unfortunately part of being an adult is realizing there are no bullies. There are adults with power and some people who wield unfairly, but that’s different from a mean schoolchild, although the similarities are there. I don’t think the people who work on browser standards are bullies and it’s weird to frame them in that way.
> Where's the equality in that?
I guess why do you think there should be equality between users and the people that work on browser standards? It’s a committee not a direct democracy. Although they do take user feedback seriously, they surely can’t only do what every vocal minorities wants right?
> Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
They’re not be disrespectful by moderating the thread. They’re simply trying to do their jobs without being insulted constantly. It’s a bit different. They are actively responding respectfully to the feedback, I don’t think they’re hurting people.
> But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
How could it be more collaborative? It’s already a request for feedback on an open forum. The comments aren’t even deleted just hidden because they’re duplicates. I’m curious what could be more collaborative?
Unfortunately part of being an adult is realizing there are no bullies. There are adults with power and some people who wield unfairly, but that’s different from a mean schoolchild, although the similarities are there. I don’t think the people who work on browser standards are bullies and it’s weird to frame them in that way.
> Where's the equality in that?
I guess why do you think there should be equality between users and the people that work on browser standards? It’s a committee not a direct democracy. Although they do take user feedback seriously, they surely can’t only do what every vocal minorities wants right?
> Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
They’re not be disrespectful by moderating the thread. They’re simply trying to do their jobs without being insulted constantly. It’s a bit different. They are actively responding respectfully to the feedback, I don’t think they’re hurting people.
> But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
How could it be more collaborative? It’s already a request for feedback on an open forum. The comments aren’t even deleted just hidden because they’re duplicates. I’m curious what could be more collaborative?
> There are adults with power and some people who wield unfairly
Bullies, the mafia… it's a question of scale really.
Bullies, the mafia… it's a question of scale really.
> 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'.
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'.
> Why shouldn't people be overly emotional?
By definition overly emotional is bad – that’s what separates “overly emotional” from just “emotional”.
Regardless, having emotions is not the problem, lashing out at others because of those emotions is the problem.
> These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback.
The person you are responding to said:
> we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
Why are you misrepresenting this as “it will make me sad”?
By definition overly emotional is bad – that’s what separates “overly emotional” from just “emotional”.
Regardless, having emotions is not the problem, lashing out at others because of those emotions is the problem.
> These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback.
The person you are responding to said:
> we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
Why are you misrepresenting this as “it will make me sad”?
> By definition overly emotional is bad – that’s what separates “overly emotional” from just “emotional”.
Human reactions are by definition not bad. They are a genuine expression of how we feel. We use that to signal our emotional state to others.
Try an experiment for me. Tell your partner that you want to split up. Once they finish crying, tell them that they're being "overly" emotional. See how that goes for you.
> Why are you misrepresenting this as “it will make me sad”?
Your mental model of the world has to include that other people have emotions, right? When you announce a change, you know that some people are going to be upset by it. That means you need to craft your message to account for other people's reactions.
Much like the above experiment, email your mother and tell her that you've decided that calling her every week is too much of a hassle and you're not going to do it any more. What do you think her reaction would be?
Perhaps you have a genuine reason for doing so. How would you best communicate that with her? What mitigation strategies would you use? What would you be prepared to compromise on?
Gatekeepers are usually terrible at accounting for the emotions of others. This is a repeated pattern and, by now, shouldn't be surprising to them.
Human reactions are by definition not bad. They are a genuine expression of how we feel. We use that to signal our emotional state to others.
Try an experiment for me. Tell your partner that you want to split up. Once they finish crying, tell them that they're being "overly" emotional. See how that goes for you.
> Why are you misrepresenting this as “it will make me sad”?
Your mental model of the world has to include that other people have emotions, right? When you announce a change, you know that some people are going to be upset by it. That means you need to craft your message to account for other people's reactions.
Much like the above experiment, email your mother and tell her that you've decided that calling her every week is too much of a hassle and you're not going to do it any more. What do you think her reaction would be?
Perhaps you have a genuine reason for doing so. How would you best communicate that with her? What mitigation strategies would you use? What would you be prepared to compromise on?
Gatekeepers are usually terrible at accounting for the emotions of others. This is a repeated pattern and, by now, shouldn't be surprising to them.
> > By definition overly emotional is bad
> Human reactions are by definition not bad.
I said “overly emotional” was bad by definition, not “human reactions”. Don’t change my words then argue against what you changed them to.
> Try an experiment for me. Tell your partner that you want to split up. Once they finish crying, tell them that they're being "overly" emotional. See how that goes for you.
Why? They would not be overly emotional. Crying in response to being broken up with is a normal amount of emotion. Same goes for the mother example.
The whole point of overly emotional is that it is a label that specifically describes the emotions as being in excess. The label means “bad” – it’s bad by definition. If it were not bad in this way, then it would just be “emotional”, not “overly emotional”. Attaching “overly” is describing it as bad.
> > Why are you misrepresenting this as “it will make me sad”?
You did not even attempt to answer this.
GP said they received hate and insults. You misrepresented that as “it will make me sad”. Hate and insults are not somebody saying “it will make me sad”. You misrepresented what GP was saying. Why?
> Human reactions are by definition not bad.
I said “overly emotional” was bad by definition, not “human reactions”. Don’t change my words then argue against what you changed them to.
> Try an experiment for me. Tell your partner that you want to split up. Once they finish crying, tell them that they're being "overly" emotional. See how that goes for you.
Why? They would not be overly emotional. Crying in response to being broken up with is a normal amount of emotion. Same goes for the mother example.
The whole point of overly emotional is that it is a label that specifically describes the emotions as being in excess. The label means “bad” – it’s bad by definition. If it were not bad in this way, then it would just be “emotional”, not “overly emotional”. Attaching “overly” is describing it as bad.
> > Why are you misrepresenting this as “it will make me sad”?
You did not even attempt to answer this.
GP said they received hate and insults. You misrepresented that as “it will make me sad”. Hate and insults are not somebody saying “it will make me sad”. You misrepresented what GP was saying. Why?
OK, so what makes you the arbiter of when an emotion is "in excess"?
Your partner crying at being broken up with is OK by you. What if they call you a rude name? Or throw crockery? Who decides that the emotions they are showing are bad?
> Hate and insults are not somebody saying “it will make me sad”. You misrepresented what GP was saying. Why?
"How dare you break up with me! You bastard!"
"Whoa! There's no need for rude language!"
Humans use language to indicate their strength of feeling. My reading of the GitHub thread is of people politely replying with several reasons why they don't want this change. When Chrome then ignores them, the people escalate their language to make their strength of feeling known.
This is a normal feature of human language. This is how humans have communicated for millennia.
Your partner crying at being broken up with is OK by you. What if they call you a rude name? Or throw crockery? Who decides that the emotions they are showing are bad?
> Hate and insults are not somebody saying “it will make me sad”. You misrepresented what GP was saying. Why?
"How dare you break up with me! You bastard!"
"Whoa! There's no need for rude language!"
Humans use language to indicate their strength of feeling. My reading of the GitHub thread is of people politely replying with several reasons why they don't want this change. When Chrome then ignores them, the people escalate their language to make their strength of feeling known.
This is a normal feature of human language. This is how humans have communicated for millennia.
> OK, so what makes you the arbiter of when an emotion is "in excess"?
You asked:
> Why shouldn't people be overly emotional?
I am not the arbiter. I am not calling any particular thing overly emotional. I am merely pointing out that overly emotional is bad by definition. People should not be overly emotional because it’s overly emotional. It’s bad by definition.
> Hate and insults are not somebody saying “it will make me sad”. You misrepresented what GP was saying. Why?
You are still avoiding this question.
You asked:
> Why shouldn't people be overly emotional?
I am not the arbiter. I am not calling any particular thing overly emotional. I am merely pointing out that overly emotional is bad by definition. People should not be overly emotional because it’s overly emotional. It’s bad by definition.
> Hate and insults are not somebody saying “it will make me sad”. You misrepresented what GP was saying. Why?
You are still avoiding this question.
> OK, so what makes you the arbiter of when an emotion is "in excess"?
The ability to form their own opinion.
And I take you meant to say, "the display of an emotion" being in excess.
> This is a normal feature of human language. This is how humans have communicated for millennia.
Really? An appeal to tradition?
As if people trying to control their emotions and trying to deescalate and debate it out wasn't a millennias old tradition...
The ability to form their own opinion.
And I take you meant to say, "the display of an emotion" being in excess.
> This is a normal feature of human language. This is how humans have communicated for millennia.
Really? An appeal to tradition?
As if people trying to control their emotions and trying to deescalate and debate it out wasn't a millennias old tradition...
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-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.
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-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.
It's disheartening that this Chrome dev in the comments shows himself to be completely unaware of the RSS ecosystem...
Quite frankly i think if browsers had better default display of RSS then it wouldnt really matter.
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.
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.
Take a look at this 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:
https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-...
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"?>
https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-...
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.
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.
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.
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.
> 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.... should definitely not be included in that telemetry at all, indicating the value should be much higher
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.... should definitely not be included in that telemetry at all, indicating the value should be much higher
Even skechers.com doesn't use it any more [1]
[1] https://thedailywtf.com/articles/Sketchy-Skecherscom
[1] https://thedailywtf.com/articles/Sketchy-Skecherscom
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.
Securing an XSLT 3.0 implementation would be much easier.
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.
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.
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.
Firefox at least did have a sensible default style sheet for RSS at some point.
I always kind of liked XSLT but it clearly has not caught on.
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.
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.
I think most people just aren't aware its available in the browser.
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?
That polyfill is 46 Megabytes in size. This would suck so much to have this suddenly in the build.
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
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.
XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):
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.
> 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.
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.
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
Why can’t things remain backwards compatible forever? In the 35 years that the Web has existed, browsers have come pretty damn close to meeting that standard. The one huge exception is the removal of plugin support around 2015, and the concomitant death of Flash and Java applets. There were also some major browser-specific APIs that got killed off, like ActiveX and NaCl. But when it comes to standardized, browser-native functionality… very little has ever been removed. I would prefer it if I could say the same thing in another 35 years.
> Why can’t things remain backwards compatible forever?
I already said why:
> The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
If you read the GitHub issue that this submission links to, the issue points out security vulnerabilities and links to:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
I already said why:
> The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
If you read the GitHub issue that this submission links to, the issue points out security vulnerabilities and links to:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
for those who have been looking, the actual presentation where they talk about this appears to be here: https://youtu.be/U1kc7fcF5Ao
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.
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.
> 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.)
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.)
As if oligopolization of the browser space wasn't a deliberate objective of the WHATWG.
I would rather have them deprecate the HTML syntax, which is a nightmare to parse, nightmare to escape for ( https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... ), and nightmare to securely transform (CVE-2020-26870). Now that MSIE is dead, all mainstream browsers support XHTML just fine; compared to HTML, XML is much, much simpler to make a new implementation of; and few people generate markup by printf any more.
I would rather have them deprecate the HTML syntax, which is a nightmare to parse, nightmare to escape for ( https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... ), and nightmare to securely transform (CVE-2020-26870). Now that MSIE is dead, all mainstream browsers support XHTML just fine; compared to HTML, XML is much, much simpler to make a new implementation of; and few people generate markup by printf any more.
> As if oligopolization of the browser space wasn't a deliberate objective of the WHATWG.
So why is it that when once in a blue moon the WHATWG tries to do something that also happens to help new implementations, web devs come in to cry bloody murder? Maybe there are co-conspirators to the scheme? :)
So why is it that when once in a blue moon the WHATWG tries to do something that also happens to help new implementations, web devs come in to cry bloody murder? Maybe there are co-conspirators to the scheme? :)
> 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.
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.
> No, adding complex new interfaces and then demanding that every
browser implement them quickly is what does that.
New interfaces forced into the spec without concern for complexity have led to the demise of existing browser engines.
But the lack of new implementations is also a result of the insistence on keeping all obsolete interfaces, no matter how complex or how little their remaining usefulness, at all cost. (Looking at you, document.write...)
> > a) freeze the standard
> Yes, or rather new features should become rarer over time.
This is far more unrealistic than dropping XSLT support.
New interfaces forced into the spec without concern for complexity have led to the demise of existing browser engines.
But the lack of new implementations is also a result of the insistence on keeping all obsolete interfaces, no matter how complex or how little their remaining usefulness, at all cost. (Looking at you, document.write...)
> > a) freeze the standard
> Yes, or rather new features should become rarer over time.
This is far more unrealistic than dropping XSLT support.
Thing is the new APIs added to the web are generally quite well specified with quite good tests. These older legacy APIs sometimes don't even have a standard and almost definitely don't have interoperability (XSLT is an example of one that definitely does not work consistently between WebKit/Blink and Firefox).
For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns).
Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.
For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns).
Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.
If you want to build a stable platform: never.
Absolute stability in that manner is nearly never the goal. Plenty of web standards have been deprecated. They gently push things in a direction and cull what is seen as low value or high risk.
I'm not advocating for or against this specific item, just saying we shouldn't perpetually add and bloat future maintenance demands just because we want to support every single thing that's ever been built. We should be able to remove/delete/deprecate in a way that allows reasonable notice to those that could be effected. I'm certainly not advocating for sweeping breaking changes like may be found in some web frameworks, etc. We should expect that browsers move slowly. But there still needs to be some process for culling things IMO.
I'm not advocating for or against this specific item, just saying we shouldn't perpetually add and bloat future maintenance demands just because we want to support every single thing that's ever been built. We should be able to remove/delete/deprecate in a way that allows reasonable notice to those that could be effected. I'm certainly not advocating for sweeping breaking changes like may be found in some web frameworks, etc. We should expect that browsers move slowly. But there still needs to be some process for culling things IMO.
The web platform has repeatedly removed features like this in the past, and it’s the most stable platform in the history of the computer industry.
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
How great that five years later WebGPU is something we can rely on in portable way. /s
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&...
Sorry if this is too off topic, it just triggered some memories
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&...
Sorry if this is too off topic, it just triggered some memories
> 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.
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.
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.
By terrible i just mean the code was really hacky. I was a newbie and exploring.
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
Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...
Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...
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.".
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."
In order to reach that point faster, never improve the feature and make it increasingly cumbersome to use to turn potential users off it.
And that has definitely happened with XSLT. Ancient version, incomplete feature support and behaviour, terrible debugging experience…
That was the actual answer, but those comments got hidden and the discussion locked.
Because not everything should be kept in browsers for all eternity? Thankfully it isn't like that and things do get removed.
They absolutely should and this should be considered when adding new features. That's called having a stable platform that others can build upon.
I think you don't know how much has already been removed and we're absolutely fine without those features.
Tell me. I cannot, off the top of my head, think of a single feature that shipped across all major browsers that has been removed.
(For example: <blink> was never in WebKit or IE; Web SQL was never in Firefox or IE.)
Well, OK, I’ll count SharedArrayBuffer, which shipped across the board for a couple of months before being disabled for security reasons, and took up to four years before being shipped again, in slightly restricted form.
I wouldn’t count applets or plugins like Flash, because they weren’t really part of the web platform, and they also still work in theory, it’s just that the plugins in question no longer exist.
(For example: <blink> was never in WebKit or IE; Web SQL was never in Firefox or IE.)
Well, OK, I’ll count SharedArrayBuffer, which shipped across the board for a couple of months before being disabled for security reasons, and took up to four years before being shipped again, in slightly restricted form.
I wouldn’t count applets or plugins like Flash, because they weren’t really part of the web platform, and they also still work in theory, it’s just that the plugins in question no longer exist.
I recall FTP support being very widespread. I'm sure JavaScript support has gone through massive changes. There have been other HTML tags deprecated. There's plenty of (security) headers that have been deprecated.
I wouldn’t call FTP part of the web platform—it was never integrated. All you could do was link to it, and then the browser might be able to render it itself (Firefox and Chromium, until a few years ago), or open another app that could (IE and Safari, and Firefox and Chromium probably can still).
JavaScript has added things, not removed them.
There are other HTML elements and attributes that were never in any spec and were supported by only some browsers, which are no longer supported (either it was IE, or the feature was removed), and explicitly described as obsolete in the HTML Standard. But they were never supported by more than two of the three or four main engines, or if they were their functionality has been retained.
So, if you have anything that has actually been removed from the web platform, please be more specific.
JavaScript has added things, not removed them.
There are other HTML elements and attributes that were never in any spec and were supported by only some browsers, which are no longer supported (either it was IE, or the feature was removed), and explicitly described as obsolete in the HTML Standard. But they were never supported by more than two of the three or four main engines, or if they were their functionality has been retained.
So, if you have anything that has actually been removed from the web platform, please be more specific.
Mutation Events were once in all 3 moderns engines plus some legacy ones and is now removed from everything.
Third-party cookies are now heavily restricted and while not quite removed everywhere cannot be relied upon.
document.domain is no longer settable by default in Chromium, and other browsers are aligned on matching this.
There's other APIs that have been restricted to secure contexts only.
The list goes on and on, the idea that the web is this unbreakable surface isn't true. It does break things and that is a good thing, if you want the platform to succeed for decades to come they should be able to fix mistakes.
Third-party cookies are now heavily restricted and while not quite removed everywhere cannot be relied upon.
document.domain is no longer settable by default in Chromium, and other browsers are aligned on matching this.
There's other APIs that have been restricted to secure contexts only.
The list goes on and on, the idea that the web is this unbreakable surface isn't true. It does break things and that is a good thing, if you want the platform to succeed for decades to come they should be able to fix mistakes.
> But they were never supported by more than two of the three or four main engines, or if they were their functionality has been retained.
Isn't this the same as a feature being removed from the web platform? If not, then what are the exact engines I need to consider to think of a a feature that has been removed?
Isn't this the same as a feature being removed from the web platform? If not, then what are the exact engines I need to consider to think of a a feature that has been removed?
This is all stuff from the turbulent times where Netscape Navigator and Internet Explorer were frequently doing different and incompatible things. I don’t think any of the things that actually got removed were even supported by both of them.
Can't they make a memory safe XSLTProcessor by just compiling libxml to WebAssembly?
[deleted]
Obligatory xkcd: https://xkcd.com/1172/
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.
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.
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.
[deleted]
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...
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...
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.
And well, the browser tries to be the only program one uses, where all applications run inside 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://temp.chrismorgan.info/2022-05-10-rss.xsl.)