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

61–70 of 99 posts

Re: Should we remove XSLT from the web platform?

#61

Post by chrismorgan »

Avamander wrote: post #46
account42 wrote: post #44

Earlier quoted context omitted.

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

Re: Should we remove XSLT from the web platform?

#62

Post by jongjong »

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…

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.

Re: Should we remove XSLT from the web platform?

#63

Post by chrismorgan »

naniwaduni wrote: post #58
bitwize wrote: post #43

Earlier quoted context omitted.

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…

Re: Should we remove XSLT from the web platform?

#64

Post by chrismorgan »

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://temp.chrismorgan.info/2022-05-10-rss.xsl.)

Re: Should we remove XSLT from the web platform?

#65

Post by perching_aix »

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

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

Re: Should we remove XSLT from the web platform?

#66

Post by Avamander »

JimDabell wrote: post #59
Avamander wrote: post #37

Earlier quoted context omitted.

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.

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

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.

Re: Should we remove XSLT from the web platform?

#67

Post by em-bee »

JimDabell wrote: post #25
comex wrote: post #17

Earlier quoted context omitted.

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

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

for those who have been looking, the actual presentation where they talk about this appears to be here: https://youtu.be/U1kc7fcF5Ao

Re: Should we remove XSLT from the web platform?

#68

Post by Avamander »

chrismorgan wrote: post #61
Avamander wrote: post #46

Earlier quoted context omitted.

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

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.

Re: Should we remove XSLT from the web platform?

#69

Post by shiomiru »

account42 wrote: post #56
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…

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

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

Re: Should we remove XSLT from the web platform?

#70

Post by chrismorgan »

Avamander wrote: post #68
chrismorgan wrote: post #61

Earlier quoted context omitted.

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

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.

Post reply on HN