They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.
There is really no winning for them. They weren't even the party who proposed removing xslt.
Like HN isn't on these type of topics. Just an hour ago you said that they're trying to kill XSLT because it "not a tool for surveillance capitalism"[1]. A claim made completely unencumbered by any evidence, of course. It's little more than a nonsensical conspiracy theory.
There's a reason all the major browsers are kind of on-board with this, just like there's a reason it never got updated much beyond XSLT 1. If XSLT would be proposed today, adding it to browsers would be a complete non-starter. Newer browsers like Servo or Ladybird have not even mentioned XSLT as near as I can find. It's very low low on their priority list, and I wouldn't be surprised if at least some people working on those browsers would prefer to not implement it at all.
The funny thing about people stuck in echo chambers is that they cannot comprehend how anyone could disagree with them, so then they reach to conspiracy theories to "explain" this, completely ignoring all the technical arguments.
If HTML didn't exist and was proposed today (please forgive the forced hypothetical) it would be a non-starter. Every tech-startup would instead want you to use their dedicated app. We rarely create shared standards or protocols anymore. We should at least keep the ones we have.
"XSLT isn't a tool for surveillance capitalism, nor for glossy product brochure presentation, nor for captive passive doomscrolling video experiences, so it must be actively excised from the global knowledge network hypermedia standard"
If that's not saying "they're doing it because [..]" then I don't know what it's saying.
> I think a key problem here has nothing to do with the merits of XSLT, but is that some parties involved have no credibility when it comes to their intentions.
There is a long history of conflicts of interest in Web standards (de jure and de facto), and my point is that regardless of the merits of removing XSLT there's a big problem of the lack of credibility of some.
It's that history and credibility that is inviting impassioned pushback.
The dialogue makes a lot more sense once we realize the credibility problem.
If we ignore that credibility problem, we'll be banging our heads against the wall with how crazy the dialogue is.
Once we acknowledge the problem, we might be able to move forward, and perhaps even improve the root problem.
You said what you said in that thread. And your "clarification" here adds little nuance to it.
1. "Play Nice": Browser vendors are trying to do what’s right for the web with budgets that are substantially outside their control. But browser vendors have the right to control their budgets, and to make decisions about what features to support or not to support. Web developers have to persuade browser vendors in order to get what they want; they have no special moral rights here. It is both practical and ethical to treat browser vendors politely, and not to rudely shame them.
(Eric Meyer's blog post here is firmly in the "Play Nice" point of view. "Google has trillions of dollars," he writes. "The Chrome team very much does not.")
2. "Fight the Power": Browser vendors are in a position of power, and that creates a moral responsibility to web developers. Their budgets are substantially within their control, and if their moral duty requires them to spend more on browser development, then that’s what duty requires. Frequently, browser vendors will try to shirk their duty to web developers in order to manage their budgets; this is always wrong, every time they do it.
There are two sub-bullets under "Fight the Power."
2a. When browser vendors shirk their responsibility, we all have a duty to shame the ones doing it in a noisy protest, not because that’s a practical way to persuade browser vendors, but because protesting/shaming wrongdoers in positions of power is ethical for its own sake.
2b. Browser vendors will try to shield themselves from protests by putting “code of conduct” rules in place against protesting/shaming them, especially against personal attacks. But it’s unethical for browser vendors (actors in a position of power) to enforce a code of conduct that prevents powerless web devs from shaming them, so the code of conduct should be protested, too; browser vendors should furthermore be shamed for having a code of conduct that interferes with the right/duty of web devs to protest shameful behavior. At a minimum, web devs should non-violently resist the code of conduct by actively violating it, and by shaming browser vendors for trying to enforce it.
I think the majority point of view here on HN is "Fight the Power." Google's up to no good, again, huh? Then we've all gotta shame them into doing the right thing again with a righteous flame war, no holds barred, including direct personal attacks. ("Should Mason Freed be removed from web standards?")
And if they try to delete/suppress our flamey personal-attack posts calling out their shameful behavior, why, that's even more shameful, and we've gotta call that out, too.
I think both points of view are reasonable. The problem is when people don't even realize that the other point of view exists.
One of the things I learned about Google during the AMP4Email fiasco is that the standards-development folks there... do not know the word no. There is no process to tell them that something should not be done. If you do, you broke the code of conduct, because they're Googlers and they Know Better. People like Mason Freed in the XSLT thread are sad that people trying to tell him no are getting in the way of him talking to people who will tell him yes.
At the point where the courts have determined that Google abuses it's monopoly control of the web, honestly, there's a question why Google is involved in standards-setting as opposed to being relegated to an advisory position required to implement standards as-designed by everyone else.
The venue is the right to fork.
The standard is made by people who write code implementing web browsers. Rando freeloaders who don't put in the work don't get a vote.
This is how the internet has always worked, to pataphrase a different standards body - running code and loose consensus.
The web is what the engines implement and what sites use. Always has been. A standard that's not implemented isn't worth anything.
Web standards exist to help browsers be interoperable. Before them one browser would implement something, and if another liked it they would too. That can still happen, but standards mediate the process to be less chaotic and more reliable.
Web standards cannot force browsers to do anything. If a browser doesn't implement a standard - and there are lot of unimplemented "standards" out there - then it just doesn't.
As a user then you have the choice to use browsers that offer better or different standards support. If you require XSLT support, and Firefox removes it, you can use Safari, or Chrome. If Chrome removes it, you can hopefully use an Blink engine that keeps the feature on (usually they're removed with a flag far before they're actually deleted with code).
And this is the real problem with a lack of browser diversity: Users need to be able to vote with their feet.
But... if all the vendors agree on something, as a user good luck with finding an alternative. I seriously doubt Opera, Brave, or Vivaldi is going to do the work and take the security risk to add back XSLT. Servo and Ladybird aren't going to come to the rescue here either. They most likely would love to have less to implement.
I agree, but this is not about that.
XSLT is implemented. Websites use it. I would argue the barrier to remove it should be incredibly high, not "we don't want to financially support the dude who maintains the library". Web standards should be close to permanent, which is why we should not add stupid ones left and right.
The problem I have in particular with how Google uses it's incredible clout to mismanage the web is it actively chips away at the web's stability. The goofiness the CA/B is up to is similar: Over 80% of organizations have outages every year due to certificate issues, and some absolutely clueless folks think 47 day certificate lifetimes is a good decision. The web in 2025 is incredibly fragile, and all signs lead to Google continuing to try to make it more fragile. You could pull in dozens of examples of centralizing forces that ensure one engineer pushing a bad configuration at one company takes down 40% of the web.
The Web is not Android. Apps on it should not break because you didn't submit a new version which updates to the latest platform framework within the last six months. Something on the web should, ideally, continue to work in perpetuity, unless acted on by an outside force (most likely by the site owner failing to continue paying the bill).
XSLT exists, it's supported by every major browser right now, and it should be nearly illegal to remove it.
Also you keep saying "Google" and ignoring that all the vendors are tentatively in support of this. What if Olli had opened the issue? He raised it at WHATNOT.
Don't you think you're being a little bit dramatic? The chances of anybody who isn't an ubernerd caring about XSLT's removal is exactly 0.
Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)
XSLT is XML, but XML isn't XSLT.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
The better phrased version of my criticism is that voice menus are generally not rendered using a web browser and thus deprecating xslt in web browsers cannot possibly affect them.
Nobody is killing xslt in general, just the web browser bindings.