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

51–60 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#51

Post by sugarpimpdorsey »

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…

> yet people would rather create more standards to avoid using it for ideological reasons

Uh the standard in question has existed for over two decades

Re: Google did not unilaterally decide to kill XSLT

#52

Post by madeofpalk »

sugarpimpdorsey wrote: post #22
simonw wrote: post #18

Earlier quoted context omitted.

Which comments did you see as being arrogant?

The one where the guy speaks for the whole Chrome team and says they want work on new stuff rather than fix things they themselves allege are broken. It's extremely ivory tower and a disservice to the web as a whole.

Wait - have you never said something similar? That would would rather address tech debt, or drop a feature that gets little use and has high maintance cost, so you can spend your effort on "better" things?

Re: Google did not unilaterally decide to kill XSLT

#53

Post by karlgkk »

nashashmi wrote: post #23

The people who use these features are busy using these features. And they are not part of browser development. So they revolt in a nasty manner. Like when ftp was torn down. It is nice to see workarounds. But those workarounds are not conducive to HTML purists who do things without JS. They are the real web developers. They have always relied on the browser to improve and become faster but not start abandoning old te…

> Like when ftp was torn down

FTP needed to be torn down. It’s sad, but true. There was no reason for anyone to be using it past 2010 - and in fact many reasons actively against using it

Re: Google did not unilaterally decide to kill XSLT

#54

Post by 6510 »

pdntspa wrote: post #42

Wouldn't it be better if all interested parties band together and put forth a XML+XSLT-to-HTML translation with a common interface, and then integrate that?

I have lots of ideas for things that can just be removed.

We could remove framesets and remove var from javascript. Remove the Date object now that there is a Temporal api. Remove tables and flexbox now that there is grid. xhr can go too now that we have fetch. The tag isn't needed anymore. I'm sure we can find support from people disliking onclick and onsomething attributes. Or how about hoisting? Surely we can simply rm that? Removing things doesn't have to be limited to older things. asm.js and web workers weren't really necessary at all.

I'm fountain of good ideas.

Re: Google did not unilaterally decide to kill XSLT

#55

Post by cosmic_cheese »

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…

That’s not nearly as nice as being able to drop a…
…in anywhere you want a header. It being part of HTML also allows engines to optimize in ways that otherwise wouldn’t be possible and implement user-toggleable features like lazy loading. It can get better as browsers get better and is less likely to break than any custom JS I write.

Re: Google did not unilaterally decide to kill XSLT

#56

Post by spankalee »

ocdtrekkie wrote: post #19
_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.

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…

Also, Mason is one if the nicest guys I know, and this is his job. I really don't think he's sad about a bunch of people misinterpreting what's going on and freaking out about it.

Re: Google did not unilaterally decide to kill XSLT

#57

Post by oorza »

nashashmi wrote: post #23

The people who use these features are busy using these features. And they are not part of browser development. So they revolt in a nasty manner. Like when ftp was torn down. It is nice to see workarounds. But those workarounds are not conducive to HTML purists who do things without JS. They are the real web developers. They have always relied on the browser to improve and become faster but not start abandoning old te…

> HTML purists who do things without JS. They are the real web developers.

I don't think using one set of technologies as compared to another one can really be said to make one a "real" web developer. Real web developers are developers who put sites on the web, there is no benefit to anyone to be had claiming one choice is "real" and therefore the other choices are lesser-than.

Put it this way: whatever set of constraints you used to arrive at that decision does not apply to every situation, and when you frame things through the lens where you implicitly disregard that oh-so-obvious truth, it's hard for anyone to interpret your analysis as anything but myopic in the best case and actively self-serving and destructive in the worst case. It's nearly impossible to read through someone speaking this way about a topic and believe their analysis is objective, comprehensive, or without obvious bias, even if it may actually be all of those things.

Re: Google did not unilaterally decide to kill XSLT

#58

Post by layer8 »

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…

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

Re: Google did not unilaterally decide to kill XSLT

#59

Post by dkiebd »

throw7 wrote: post #11

My jotted down notes: 1. all major vendors (google, mozilla, webkit) want to remove xslt 2. chrome does not have resources to support xslt 3. removing/disabling xslt will be a slow methodical process. don't panic. 4. when opening a proposal change, a pull request of code changes is mandatory to show exact changes; it is not a "countdown to merge"(sic) 5. info that leaks to the public should include context or links t…

3. It will eventually be removed. Does it matter whether it will take three months or three years? Since I suppose none of the browser vendors will give developers money to change their xslt usage in codebases for something else.

5. Funny that we are talking about "info that leaks to the public" when we are discussing standards that may be important to billions of people, as if keeping things private was reasonable.

Re: Google did not unilaterally decide to kill XSLT

#60

Post by ocdtrekkie »

spankalee wrote: post #45
ocdtrekkie wrote: post #19

Earlier quoted context omitted.

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…

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

Post reply on HN