41–50 of 138 posts
That's good. It's good that everyone is on board with removing such a pointless feature that comes with a significant maintenance burden and security risks.
That's a great view to have if you're someone that switches jobs every six months and never supports anything for any meaningful length of time.
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. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.
> they operate in a self-serving echo chamber. 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…
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. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.
This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours , not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. One of the things I learned about Google during the AMP4Email fiasco is that the st…
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.
XLST is a really weird feature and it seems sensible to drop it, be nice if there is a transparent solution for old software that uses it.
Earlier quoted context omitted.
Well yes? People get to decide what to do with their own money, and managers get to decide what to do with the companies' money. That's basically what being a manager means in the first place. They decided spending that money on maintaining a barely used feature was not a very good use of the budget, and that it might be better spent on something that people actually use.
And so would that be a thing we can maybe have an issue with? The entire "handwaving away" bit is the fact that moving a decision another layer up a hierarchy doesn't change who is responsible or how that responsibility manifests, a different problem then "they get to decide on how they spend their money" - we don't have the resources vs we are not going to use them on what you want (which itself is something that is…
I hope some form of include makes it into the HTML standard and popular browser implementations before XSLT is gone. It’s perhaps the single largest gap in HTML’s capabilities and could reduce need for SSR, JS, and a build step in a lot of circumstances. Until now XSLT has been able to fill that gap for those who need that capability, but if it’s going away…
customElements.define(
"html-include",
class extends HTMLElement {
connectedCallback() {
fetch(this.getAttribute("href"))
.then((response) => response.text())
.then((text) => (this.innerHTML = text))}});
So from a technical standpoint, I do understand those calling for it to be eventually removed.
Earlier quoted context omitted.
> they operate in a self-serving echo chamber. 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…
I didn't say that's why they were doing it.
"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.