Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google did not unilaterally decide to kill XSLT

meyerweb.com

Post reply on HN
Print view View original

61–70 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#61

Post by _bzuf »

arp242 wrote: post #50
_bzuf wrote: post #44

Earlier quoted context omitted.

I didn't say that's why they were doing it.

Mate ... Your full comment: "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 made my point more clear in this later comment thread, in which we are talking, where I said:

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

Re: Google did not unilaterally decide to kill XSLT

#62

Post by _Algernon_ »

arp242 wrote: post #40
_bzuf wrote: post #12

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…

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

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.

Re: Google did not unilaterally decide to kill XSLT

#63

Post by scrollaway »

Fun fact - A very old version of the "WoW Armory", which was Blizzard Entertainment's World of Warcraft database at https://wowarmory.com/ used XSLT for all of its styling - though, IIRC, only on Firefox which was the only web browser to properly implement it.

The website's "item" and "character" pages were served entirely in XML.

Here's a web archive: https://web.archive.org/web/20080220170805/https://wowarmory...

(dead_dove.gif)

Re: Google did not unilaterally decide to kill XSLT

#64

Post by spankalee »

ocdtrekkie wrote: post #60
spankalee wrote: post #45

Earlier quoted context omitted.

I think there's a fundamental misunderstanding of what standards are here. 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…

> A standard that's not implemented isn't worth anything 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…

The barrier is incredibly high. I'd be pretty surprised if this process takes less than five years because the bar is so high.

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.

Re: Google did not unilaterally decide to kill XSLT

#65

Post by worble »

I do not understand how this can possibly be considered. It comes down to one question: will this break websites that are in production right now?

If the answer is yes then it can't be done, simple as. I really don't care about anything else, you can't just break the web for people who are actively using it.

Re: Google did not unilaterally decide to kill XSLT

#66

Post by joshuamorton »

th0ma5 wrote: post #36
samdoesnothing wrote: post #29

Earlier quoted context omitted.

> while they destroy the web 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.

XSLT specifics? Yes, ubernerd ... Person who can't get a doctor's appointment because the interactive voice menu which is somehow now based on a browser engine and has a subtle bug caused by this change could be anyone.

Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)?

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)

Re: Google did not unilaterally decide to kill XSLT

#67

Post by 6510 »

layer8 wrote: post #58
samdoesnothing wrote: post #48

Earlier quoted context omitted.

There is no point of introducing yet another standard to do something that can be done in few lines of JS. customElements.define( "html-include", class extends HTMLElement { connectedCallback() { fetch(this.getAttribute("href")) .then((response) => response.text()) .then((text) => (this.innerHTML = text))}}); The browser has had a powerful scripting language built in as a core primitive for decades, and yet people wo…

We should drop HTML and CSS files as well, because you can just use JS to create DOM nodes and set styles on them.

One of the greatest features of pdf is that js support is unreliable.

Re: Google did not unilaterally decide to kill XSLT

#68

Post by spankalee »

cosmic_cheese wrote: post #28

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…

https://github.com/WICG/declarative-partial-updates

Re: Google did not unilaterally decide to kill XSLT

#69

Post by naniwaduni »

samdoesnothing wrote: post #48
cosmic_cheese wrote: post #28

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…

There is no point of introducing yet another standard to do something that can be done in few lines of JS. customElements.define( "html-include", class extends HTMLElement { connectedCallback() { fetch(this.getAttribute("href")) .then((response) => response.text()) .then((text) => (this.innerHTML = text))}}); The browser has had a powerful scripting language built in as a core primitive for decades, and yet people wo…

It's something that people keep reinventing on both sides of the connection. That XSLT is the better of two terrible ways to do it, and that you're making the argument that the other one still exists, is an embarrassment.

Re: Google did not unilaterally decide to kill XSLT

#70

Post by spankalee »

worble wrote: post #65

I do not understand how this can possibly be considered. It comes down to one question: will this break websites that are in production right now? If the answer is yes then it can't be done, simple as. I really don't care about anything else, you can't just break the web for people who are actively using it.

Removing Flash, Mutation Events, and third-party cookies broke websites.
Post reply on HN