>I use both the JavaScript "XSLTProcessor" functions [0] and "<?xml-stylesheet …?>" [1] on my personal website

You are on some very very small elite team of web standards users then

FYI: Many Firefox and Thunderbird extensions use <?xml-stylesheet?> . Perhaps not XSLTProcessor though.

WebExtensions still have them? I thought the move to HTML (for better or worse) would've killed that. Even install.rdf got replaced IIRC so there shouldn't be much traces of XML in the new extensions system...

Small, sure, but not elite. xml-stylesheet is by far the easiest way to make a simple templated website full of static pages. You almost could not make it any simpler.

> but a page like this is more likely to annoy the decision-makers than to convince them to not remove XSLT support.

You cannot “convince decision-makers” with a webpage anyway. The goal of this one is to raise awareness on the topic, which is pretty much the only thing you can do with a mere webpage.

For some reason people seem to think raising awareness is all you need to do. That only works if people already generally agree with you on the issue. Want to save endangered animals? raising awareness is great. However if you're on an issue where people are generally aware but unconvinced, raising more awareness does not help. Having better arguments might.

> For some reason people seem to think raising awareness is all you need to do.

I don't think many do.

It's just that raising awareness is the first step (and likely the only one you'll ever see anyway, because for most topics you aren't in a position where convincing *you* in particular has any impact).

Convincing me personally does not have any impact. Convincing people like me, in mass, does.

A mass doesn't move because it's convinced (i.e. rationally) of something, but because they are emotionally impacted.

Rational arguments come later, and mostly behind closed doors.

My emotional response to XSLT being removed was: "finally!". You would need some good arguments to convince me that despite my emotions applauding this descion it is actually a bad thing.

You're simply not a good target to advocate to on this particular topic. And it's fine, actually.

Sure, but translating that movement to actual policy change usually depends on how much uninvolved people are sympathetic to the protestors, which usually involves how rational the protestors are precieved as. Decision makers are affected by public sentiment, but public sentiment of the uninvolved public generally carries more weight.

Thats why the other side usually try to smear protests as being crazy mobs who would never be happy. The moment you convince uninvolved people of this, the protestors lose most power.

> Rational arguments come later, and mostly behind closed doors.

I disagree with this. Rational arguments behind closed doors happen before resorting to protest not after. If you're resorting to protest you are trying to leverage public support into a more powerful position. That's about how much power you have not the soundness of your argument.

> Sure, but translating that movement to actual policy change usually depends on how much uninvolved people are sympathetic to the protestors

No, that's the exception rather than the rule. That's a convenient thing to teach to the general public and that's why people like MLK Jr. and Gandhi are being celebrated, but most movement that make actual policy changes do so while disregarding bystanders entirely (or even actively hurting bystanders. That's why terrorism, very unfortunately, is effective in practice).

> which usually involves how rational the protestors are precieved as

I'm afraid most people don't really care about how rational anyone is perceived at. Trump wouldn't have been elected twice if that was the case.

> Decision makers are affected by public sentiment, but public sentiment of the uninvolved public generally carries more weight.

They only care about the sentiment of the people that can cause them nuisance. A big crowd of passively annoyed people will have much less bargaining power than a mob of angry male teenagers doxxing and mailing death threats: see the gaming industry.

> I disagree with this. Rational arguments behind closed doors happen before resorting to protest not after.

Bold claim that contradicts the entire history of social conflicts…

>For some reason people seem to think raising awareness is all you need to do.

I guess I'm not seeing how that follows. It can still be complimentary to the overall goal rather than a failure to understand the necessity of persuasion. I think the needed alchemy is a serving of both, and I think it actually is trying to persuade at least to some degree.

I take your point with endangered animal awareness as a case of a cause where more awareness leads to diminishing returns. But if anything that serves to emphasize how XSLT is, by contrast, not anywhere near "save the animals" level of oversaturation. Because save the animals (in some variation) is on the bumper sticker of at least one car in any grocery store parking lot, and I don't think XSLT is close to that.

I think it's the other way around. Simply raising awareness about endangered animals may be enough to gain traction since many/most people are naturally sympathetic about it. Conversely, XSLT being deprecated has lower awareness initially, but when you raise it many people hearing that aren't necessarily sympathetic - I don't think most engineers think particularly fondly about XSLT, my reaction to it being deprecated is basically "good riddance, I didn't think anyone was really using it in browsers anyway".

As an open source developer, i also have a lot of sympathy to google in this situation. Having a legacy feature holding the entire project back despite almost nobody using it because the tiny fracation that do are very vocal and think its fine to be abusive to developers to get what they want despite the fact its free software they didn't pay a dime for, is something i think a lot of open source devs can sympathize with.

I think all that you say applies to a random open source project done by volunteer developers, but really doesn't in case of Google.

Google has used its weight to build a technically better product, won the market, and are now driving the whole web platform forward the way they like it.

This has nothing to do with the cost of maintaining the browser for them.

It seems likely to me that it is about the 'cost' - not literally monetary cost but one or two engineers periodically have to wrangle libxslt for Chrome and they think it's a pain in the ass and not widely used, and are now responding by saying "What if I didn't have to deal with this any more".

I'm not sure what else it would be about - I don't see why they would especially care about removing XSLT support if cost isn't a factor.

Google is still made up of people, who work a finite amount of hours in a day, and maybe have other things they want to spend their time on then maintaining legacy cruft.

There is this weird idea that wealthy people & corporations arent like the rest of us, and no rules apply to them. And to a certain extent its true that things are different if you have that type of wealth. But at the end of the day, everyone is still human, and the same restrictions still generally apply. At most they are just pushed a little further out.

My comment is not about that at all: it's a response to claim how Google SW engineering team is feeling the heat just like any other free software project, and thus we should be sympathetic to them?

I am sure they've got good reasons they want to do this: them having the same problems as an unstaffed open source project getting vocal user requests is not one of them.

>I think it's the other way around. Simply raising awareness about endangered animals may be enough to gain traction since many/most people are naturally sympathetic about it.

You're completely right in your literal point quoted above, but note what I was emphasizing. In this example, "save the animals" was offered as an example of a problem oversaturated in awareness to a point of diminishing returns. If you don't think animal welfare illustrates that particular idea, insert whatever your preferred example is. Free tibet, stop diamond trade, don't eat too much sodium, Nico Harrison shouldn't be a GM in NBA basketball, etc.

I think everyone on all sides agrees with these messages and agrees that there's value in broadcasting them up to a point, but then it becomes not an issue of awareness but willpower of relevant actors.

You also may well be right that developers would react negatively, honestly I'm not sure. But the point here was supposed to be that this pages author wasn't making the mistake of strategic misunderstanding on the point of oversaturating an audience with a message. Though perhaps they made the mistake in thinking they would reach a sympathetic audience.

>> You cannot “convince decision-makers” with a webpage anyway.

They should probably be called "decision-maders"

> but wildly misguided

Why? Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs.

I'm full in favour of removing such insecure features that barely anyone uses.

I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust. But good luck with that.

The easier thing might have been if Chrome & co opted to include any number of polyfills in JS bundled with the browser instead of making an odd situation where things just break.

I think you can recognize that the burden of maintaining a proven security nightmare is annoying while simultaneously getting annoyed for them over-grabbing on this.

libxslt != XSLT.

It's like removing JPEG support because libjpg is insecure!

Which would be a totally sensible thing you do. Especially if jpeg was a rarely used image format with few libraries supporting it, the main one being unmaintained.

Google is on a trajectory to replace jpeg with webp, haven’t you noticed?

If this were true you could fix this today with the other library. That library is the only implementation used and it’s features are relied upon.

Firefox doesn’t use libxslt. I presume IE didn’t either. It’s only WebKit-heritage browsers that use libxslt.

TIL about Firefox. They have their own in-tree solution. Very interesting but not trivial to use for external projects.

>Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs.

Being this is HN, did anyone suggest rewriting it in rust? :)

Yes: https://news.ycombinator.com/context?id=45874002

> Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs.

Sure, I agree with you there, but removing XSLT support entirely doesn't seem like a very good solution. The Chrome developer who proposed removing XSLT developed a browser extension that embeds libxslt [0], so my preferred solution would be to bundle that by default with the browser. This would:

1. Fix any libxslt security issues immediately, instead of leaving it enabled for 18 months until it's fully deprecated.

2. Solve any backwards compatibility concerns, since it's using the exact same library as before. This would avoid needing to get "consensus" from other browser makers, since they wouldn't be removing any features.

3. Be easy and straightforward to implement and maintain, since the extension is already written and browsers already bundle some extensions by default. Writing a replacement in Rust/another memory-safe language is certainly a good idea, but this solution requires far less effort.

This option was proposed to the Chrome developers, but was rejected for vague and uncompelling reasons [1].

> I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust.

That's already been done [2], but maintaining that and integrating it into the browsers is still lots of work, and the browser makers clearly don't have enough time/interest to bother with it.

[0]: https://github.com/mfreed7/xslt_extension

[1]: https://github.com/whatwg/html/issues/11523#issuecomment-315...

[2]: https://gitlab.gnome.org/World/Rust/markup-rs/xrust

From your [1] “rejected for vague and uncompelling reasons”:

>>> To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser.

>> Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I'm thinking about how Firefox renders PDFs without native code using PDF.js.)

> This is definitely something we have been thinking about. However, our current feeling is that since the web has mostly moved on from XSLT, and there are external libraries that have kept current with XSLT 3.0, it would be better to remove 1.0 from browsers, rather than keep an old version around with even more wrappers around them.

The bit that bothers me is that Google continue to primarily say they’re removing it for security reasons, although they have literally made a browser extension which is a drop-in replacement and removes 100% of the security concerns. The people that are writing about the reasons know this (one of them is the guy that wrote it), which makes the claim a blatant lie.

I want people to call Google specifically out on this (and Apple and Mozilla if they ever express it that way, which they may have done but I don’t know): that their “security” argument is deceit, trickery, dishonest, grossly misleading, a bald-faced lie. If they said they want to remove it because barely anyone uses it and it will shrink their distribution by one megabyte, I would still disagree because I value the ability to apply XSLT on feeds and other XML documents (my Atom and RSS feed stylesheets are the most comprehensive I know of), but I would at least listen to such honest arguments. But falsely hiding behind “security”? I impugn their honour.

(If their extension is not, as their descriptions have implied, a complete, drop-in replacement with no caveats, I invite correction and may amend my expressed opinion.)

an insecure mess contained in a sandbox is still an insecure mess

it just has slightly less chance of affecting something else

"effecting something else" (i.e. escaping the sandbox) is the core issue. JavaScript (and WASM) engines have to be designed to defend against the user running outright malicious scripts without those scripts being able to gain access to the rest of the browser or the host system. By comparison, potentially exploitable but non-malicious, messy code is basically a non-issue. Any attacker that found a bug in a sandboxed XSLT polyfil that allowed them to escape the sandbox or do anything else malicious would be able to just ship the same code to the browser themselves to achieve the same effect.

You still need to maintain that sandbox. Ultimately no one wants to spend energy maintaining software that isn't used very heavily. That's why feature depreciation happens. If someone cares enough, they should step in an offer to take over long term maintenance and fix the problems. Ideally a group of people, and perhaps more ideally, a group with some financial backing (eg a company), otherwise it may be difficult to actually trust that they will live up to the commitment.

Even projects like Linux deprecate old underused features all the time. At least the Internet has real metrics about API usage which allows for making informed decisions. Folks describing how they are part of that small fraction of users doesn't really change the data. What's also interesting is that a very similar group of people seem to lament about how it's impossible to write a new browser these days because there are too many features to support.

"The sandbox" in this case is their ability to execute WASM securely. It's a necessary part of the "modern" web. If they were planning on also nuking WASM from orbit because it couldn't be made secure, this would be another topic entirely. There's nothing they're maintaining just-for-xslt-1.0-support beyond a simple build of libxslt to WASM, a copy block in their build code, and a line in a JSON list to load WASM provided built-ins (which they would want anyway for other code).

The word is "deprecation", and your understanding of what it means isn't how it has tended to work at all. The Web is not the Android SDK. This is a significant change to how browser vendors treat Web standards.

I think their logic makes sense. They're removing support because of security concerns, and they're not adding support back using an extension because approximately nobody uses this feature.

Adding the support back via an extension isn't cost free.

I suppose that’s a legitimate framing. But I will still insist that, at the very least, their framing is deliberately misleading, and that saying “you can’t have XSLT because security” is dishonest.

According to the extension's README there are still issues with it, so they definitely would have to do more work.

And yeah Chrome is really strict about binary size these days. Every kB has to be justified. It doesn't support brotli compression because it would have added like 16kB to the binary size.

There is already a replacement in rust but people like you and the Google engineers have ignored that fact. “Good luck” they all say turning their nose away from reality so they can kill it. Thanks for your support.

>But I think that this website is being hyperbolic

Intentionally in a humourous way, yes

I think also literally, independent of the cheeky tone.

Where it lost me was:

>RSS is used to syndicate NEWS and by killing it Google can control the media. XSLT is used worldwide by multiple government sites. Google are now trying to control LEGISLATION. With these technologies removed what is stopping Google?

I mean yes Google lobbies, and certainly can lobby for bad things. And though I personally didn't know much of anything about XSLT, I from reading a bit about it I certainly am ready to accept the premise that we want it. But... is Google lobbying for an XSLT law? Does "control legislation" mean deprecate a tool for publishing info on government sites?

I actually love the cheeky style overall, would say it's a brilliant signature style to get attention, but I think this implying this is tied to a campaign to control laws is rhetorical overreach even by its own intentionally cheeky standards.

I think the reason you're considering it rhetorical overreach is because you're taking it seriously. If the author doesn't actually mind the removal of XSLT support (i.e. possibly rues its removal, but understands and accepts the reasons), then it's really a perfectly fine way to just be funny.

It's not. It would be an insidious way to misrepresent the positions actually held by real people instead of caricatures.

> Does "control legislation" mean deprecate a tool for publishing info on government sites?

I believe the intended meaning, in context, is "... for publishing the literal text of laws on government sites".

Right, my quote and your clarification are saying the same thing (at least that's what I had in mind when I wrote that).

But that leaves us back where we started because characterizing that as "control the laws" is an instance of the the rhetorical overreach I'm talking about, strongly implying something like literal control over the policy making process.

Laws that are designed to help you but you can't easily access, or laws that are designed to control/restrict you and that get shoved in your face: once you manage "consumption" of laws, you can push your agenda too.

At least, this is how I read that part.

I agree that you would have to believe something like that to make sense of what it's implying. But by the same token, that very contention is so implausible that that's what makes it rhetorical overreach.

It would be ridiculous to suggest that anyone's access to published legislation would be threatened by its deprecation.

This is probably the part where someone goes "aha, exactly! That's why it's okay to be deprecated!" Okay, but the point was supposed to be what would a proponent of XSLT mean by this that wouldn't count as them engaging in rhetorical overreach. Something that makes the case against themselves ain't it.

> actually love the cheeky style overall

Also towards the bottom of the site:

> Tell your friends and family about XSLT.

It's hard enough telling them to also get off Instagram and Whatsapp and switch to Signal to maintain privacy. I'm going to have a hard time explaining what XSLT is!

Can’t you just do the xslt transformation server-side? Then you can use the newest and best xslt tools, and the output will work in any browser, even browsers that never had any built-in xslt support.

> Cant you just do the xslt transformation server-side?

For my Atom feed, sure. I'm already special-casing browsers for my Atom feed [0], so it wouldn't really be too difficult to modify that to just return HTML instead. And as others mentioned, you can style RSS/Atom directly with CSS [1].

For my Stardew Valley Item Finder web app, no. I specifically designed that web app to work offline (as an installable PWA), so anything server-side won't work. I'll probably end up adding the JS/wasm polyfill [2] to that when Chrome finally removes support, but the web app previously had zero dependencies, so I'm a little bit annoyed that I'll have to add a 2MB dependency.

[0]: https://github.com/gucci-on-fleek/maxchernoff.ca/blob/8d3538...

[1]: https://news.ycombinator.com/item?id=45874305

[2]: https://github.com/mfreed7/xslt_polyfill

That is actually mozilla's stand in the linked issue except it's on client though. They would rather replace it with some non native replacement (So there is no surprising security issue anymore) if remove directly is impractical.

There is actually a example of such situation. Mozilla removed adobe pdf plugin support a long time ago and replaced it with pdf.js. It's still a slight performance regression for very giant pdf. But it is enough for most use case.

But the bottom line is "it's actually worth to do it because people are using it". They won't actively support a feature that little people use because they don't have the people to support it.

> They won't actively support a feature that little people use because they don't have the people to support it.

Companies always cut too deep. If only they were making enough money to properly support Chrome.

/sarcasm

On my blog that uses a static site generator?

Yes, it would be part of the static site generator.

Huh? How would a static site generator serve both RSS and the HTML view of the RSS from the same file?

To be extra clear: I want to have <a href="feed.xml">My RSS Feed</a> link on my blog so everyone can find my feed. I also want users who don't know about RSS to see something other than a wall of plain-text XML.

You don't serve them from the same file. You serve them from separate files.

As I mention in my other comment to you, I don't know why you want an RSS file to be viewable. That's not an expected behavior. RSS is for aggregators to consume, not for viewing.

You are being obnoxiously and unreasonably dismissive. Just because you declared they're wrong or that something is a certain way doesn't make it so.

> I don't know why you want an RSS file to be viewable.

Well, spend two seconds thinking about it. Or just, like, read what they wrote.

Technically, the web server can do content negotiation based on Accept headers with static files. But… In theory, you shouldn't need a direct link to the RSS feed on your web page. Most feed readers support a link-alternate in the HTML header:

<link rel="alternate" type="application/rss+xml" title="Blog Posts" href="/feed.xml">

Someone who wants to subscribe can just drop example.com/blog in to the feed reader and it will do the right thing. The "RSS Feed" interactive link then could go to a HTML web page with instructions for subscribing and/or a preview.

Who said "need"? He said "I want".

You're moving the goalposts.

Apply that argument to any other file format and it quickly become absurd.