“The people who actually use it are wrong and don’t matter!”

But if I were, and I were looking to decrease cost of maintenance, "This entire rendering framework that supports a 0.02% use case" would be an outlier for chopping-block consideration. Not all corner-case features match that combination of cost-to-maintain and adoption (after, what, decades at this point?).

We wouldn't be arguing the point if the feature in question were fax machine support, right?

I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.”

Totally brain dead.

Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD.

You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world.

All I can do is advocate we support many technologies and ideas. The world you are advocating sounds locked down and uninteresting.

The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing.

> You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world.

Don’t do this. We can just disagree without resorting to strawman and ad hominem attacks. No one insulted you for holding your opinion.

Before this my mental model of you was an engineer who’s frustrated that he’s going to have to do work to deal with the deprecation. I can empathize with that even if I think you are wrong in believing that browsers should invest further in support of xslt. Now I realize you just lack empathy for other engineers who are also forced to make real world trade offs. The fact that you happen to use xslt in the browser does not make it important relative to all the other features browsers support.

But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here.

There is no negative trade off by maintaining XSLT other than not being lazy developers. I have no empathy for people who hide behind billion dollar corporations and do their bidding. This is not some sort of critical situation, this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.

Only because it’s not your money or time being traded. Yes, if we pretend that engineering effort is free then there’s no reason Google couldn’t just rewrite this entire library in Rust or whatever. But if that were true you would just rewrite the library yourself and send the pull request to Chromium.

In the real world where engineering costs time and money, every decision is a trade off. Someone rewriting libxslt to be secure is someone who’s not implementing other features and who’s not fixing other bugs on the backlog.

Resources allocated to Chromium are finite and while sure, Google could hire 2 more engineers to do this, in reality those 2 new engineers could and would be assigned to higher priority work.

> this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.

You keep blaming Google specifically. All of the major browsers are planning to drop this though. They all agree this is the right trade off.

It doesn’t have to be this pearl gripping bitching and moaning about budgets and practicality. That’s just what Google wants you to believe.

No all of the major browsers weren’t planning to drop this. It literally only started happening because of Google. And Google is essentially forcing the hand. Again this is bad faith argument. I will not concede on my thoughts on this unnecessary destruction of XSLT in the browser while other technologies get a pass.

Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries.

All your “its fine to remove it” arguments only work if you ignore all the reasons it’s not fine to remove it. That’s awfully convenient.

There's a theorem with Turing's name on it that clarifies why that's equivalent.

> if you restrict rendering xslt to javascript then you lose all the performance benefits of xslt at the engine level.

Nowadays, I'd have to benchmark before just assuming the native implementation is faster. Especially if one of the issues is libxslt is under-maintained. JS is quite fast these days (and the polyfill investigated in the OP is wasm, not even JS). This problem can also be solved by moving the rendering server-side, in which case your ceiling for speed is much higher (and you're not spending your client's CPU on finishing the rendering of your page; added bonus in this era of mobile, battery-constrained devices).

> Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries.

Great point. Why do we have this one arbitrary meta-language for declarative transformation of one datatype that's "blessed" with a native implementation? That's an odd corner-case, isn't it. We should probably simplify by putting it on-par with other solutions for that problem.

I don’t know why you have a chip on your shoulder for Google but sure. Yes, Google is clearly doing this purely because they are evil and removing this little-used tech is the key to cementing their stranglehold on the internet. Yes, Google is strong-arming poor Apple and Mozilla into this. Yes, everyone who disagrees with you is both a complete moron and a “daddy Google” fanboy.

Better now?

I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side).

> not being lazy developers

Laziness is one of the three great virtues of programming. Every second not spent maintaining libxslt is a second we can spend on something more people care about.

It's a rule for writers, but it applies to software architecture also: kill your darlings.

- iced-ui browser with xslt + servo

- contribute to xslt xrust project

- investigate sandboxing xslt in firefox and implementing xrust

- same as the previous but for Chrome

- have an llm generate 1000s of static websites built in xslt and deploy them across the internet

- promote and contribute to the recent Show HN post of an xslt framework

I figure if I can generate enough effort to spam the web with xslt sites then they can’t remove it. Ultimately the first goal is to delay the removal from Chrome. This will delay the removal in other browsers. I don’t care if it’s ineffective. It’s better than doing nothing.

So you can take your lazy tenants of software engineering and your “hyuck Google knows best” eslewhere.

I think your cost / benefit analysis on maintaining a native in-browser implementation of an old, niche declarative transformation language for a hard-to-read data format that hasn't been the dominant model of sending data to browser clients for at least fifteen years is flawed, but it's not crazy. Reasonable people can certainly put their priorities in different places, and I respect our priorities don't align on this topic and you have a right to your opinion.

Is "open web" just "maximally complies with the w3c standard?"

Not: popular browsers needle through technologies and tell everyone they know best

Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using.

What is open web to you? “Overpaid Mba at Google says this is best so you better fall in line.”

The “wide range of technologies” is not what makes the web “open”.

The openness comes from the fact that anyone can write web sites and anyone can write a browser that can render the same websites that chrome can render. “More features” does not imply “more open”.

Dropping support for xslt would make the web less open if it were being replaced by some proprietary Google tech. But that’s not what’s happening here at all.

> Not: popular browsers needle through technologies and tell everyone they know best

How else would it possibly work? Everyone has to actively choose the features they will build and support.

I wish it weren't the case but good luck and I'm sure we'll speak again with nearly the same conversation at the next thread for a standard deprecation that ad companies don't like.

I was there when it was the new hottest thing and I was there when it became last year's thing. These things come and go, and this one's time has come.

I don't see how removing this API harms the open web. I do see how it imposes some nonzero cost on website maintainers to adapt to the removal of the API, and I respect that cost is nonzero.

... but I also watched OpenGL evolve into OpenGL ES and the end result was a far better API than we started with.

I don't think XSLTProcessor joining document.defaultCharset in the history books is damage to the open web.

ETA: And not that it matters over-much, but the "overpaid Mba" is an electrical engineering Ph.D who came to software via sensor manufacturing, so if you're going to attempt to insult someone's training, maybe get it right? Not that he'd be wrong if he were an Mba either, mind.

Enjoy the precedent this sets for other tech not in the Google stable. You clearly are getting what you want so why continue this discussion. Who are you trying to convince?

... and 10x the utility, since unlike XSLT Bluetooth requires sandboxed and mediated access to OS-level APIs that cannot be feature-compatible replicated with 3MB of JavaScript.

Running an XSLT engine in JavaScript is sandboxed. It's sandboxed by the JS rules. In terms of security, it's consolidating sandboxing concerns because risk of breaking XSLT becomes risk of breaking the JS engine, whereas right now there are two potential attack vectors to monitor.

(There is an unwritten assumption here: "But I can avoid the JS issues by turning off JavaScript." Which is true, but I think the ship is pretty well sailed for any w3c-compliant browser to be supporting JavaScript-off as a first-class use case these days. From a safety standpoint, we even have situations where there are security breach detections against things like iframe-busting that only work with JavaScript on).

Because they must address the security problems, there is no zero-cost solution to maintain compatibility. They either abandon it or rewrite it which comes with support costs forever.

I understand you believe they made the wrong choice and I understand why you feel that way. But according to their calculus they are making the right choice based on how widely used the feature actually is.

Piecing the puzzle pieces together from multiple threads:

There's an argument to be made that the HTML standard, which post-dates the browser wars and was more-or-less the detente that was agreed upon by the major vendors of the day, includes a rule that no compliant browser should drop a feature (no matter how old or unused that feature is) because "Don't break the web." In other words: it doesn't matter if there's zero users of something in the spec; if it's in the spec and you claim to be compliant, you support it.

XSLT has been a W3C recommendation since 1999 and XSLT2 and 3 were added later, and no W3C process has declared it dead. But several browser engines are declaring it's too cumbersome to maintain so they're planning to drop it. This creates an odd situation because generally a detente has held standards in place: you don't drop something people use because users won't perceive the sites that use the tech as broken, they'll perceive your browser is broken and go use someone else's browser.

... except that so many vendors are choosing to drop it simultaneously, and the tech is so infrequently used, that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says.

So people are concerned about a perceived shift in the practical "balance of power" between the standards and the browser developers that (reading between the lines) could usher in the bad old days of the Microsoft monopoly again, except that this time it's three or four browser vendors agreeing upon what the web should be and doing it without external input instead of Microsoft doing what it wants and Firefox fighting them / fighting to keep up. Consolidation of most of the the myriad browsers to only be running on three engines enables this.

This is coming out of WHATWG so in actuality the spec itself is being updated to remove the functionality. So yes, the end state is very much that devs cannot rely on this functionality.

From there they link to the minutes for the meeting where this was raised. Interestingly the Google engineer who raised this at the meeting was formerly at Mozilla for years. I don’t know if Mozilla was already looking to remove this or not.