Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should we remove XSLT from the web platform?

github.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Should we remove XSLT from the web platform?

#71

Post by JimDabell »

edent wrote: post #60
JimDabell wrote: post #53

Earlier quoted context omitted.

> > 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…

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…

> 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.

Re: Should we remove XSLT from the web platform?

#72

Post by Avamander »

chrismorgan wrote: post #70
Avamander wrote: post #68

Earlier quoted context omitted.

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 a…

> 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?

Re: Should we remove XSLT from the web platform?

#73

Post by pwdisswordfishz »

shiomiru wrote: post #20
3036e4 wrote: post #11

Earlier quoted context omitted.

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 deprec…

> 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…

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.

Re: Should we remove XSLT from the web platform?

#74

Post by geocar »

miki_oomiri wrote: post #5

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…

> 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?

Re: Should we remove XSLT from the web platform?

#75

Post by dev0001 »

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.

Re: Should we remove XSLT from the web platform?

#76

Post by shiomiru »

pwdisswordfishz wrote: post #73
shiomiru wrote: post #20

Earlier quoted context omitted.

> 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…

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,…

> 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? :)

Re: Should we remove XSLT from the web platform?

#77

Post by 07cwu9 »

chrismorgan wrote: post #64

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 A…

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!

Re: Should we remove XSLT from the web platform?

#78

Post by dev0001 »

miki_oomiri wrote: post #5

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 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.

Re: Should we remove XSLT from the web platform?

#79

Post by JimDabell »

07cwu9 wrote: post #77
chrismorgan wrote: post #64

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 A…

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!

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.

Re: Should we remove XSLT from the web platform?

#80

Post by conductr »

account42 wrote: post #51
conductr wrote: post #4

Earlier quoted context omitted.

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

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.

Post reply on HN