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

81–90 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#81

Post by giantrobot »

jeltz wrote: post #41
sugarpimpdorsey wrote: post #34

Earlier quoted context omitted.

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.

XSLT in the browser was always a bad idea.

What? XSLT in the browser is an awesome idea. It let web sites publish data unencumbered by presentation and let the client's user agent decide how to use the data. Your browser can download the XML and use a linked XSL stylesheet to display it for a graphical browser. That exact same data resource could be used instead by a program that understands the schema of the data and do some custom thing with it.

There's no need to trust some giant blob of JavaScript to convert a data document into a usable web page. Just the native XSLT engine (using the same XML processing pipeline it uses for all the other XML it encounters).

A web of XML documents could all be easily viewable by a web browser but the exact same data can be processed with other tools. There's a lot of old web API ideas being recycled (poorly) with JSON to service AI tools today. The web could have already been nicely structured data easily ingested by autonomous tools (AI or not) while at the same time being still perfectly accessible by graphical web browsers.

But no, everyone decided that because Enterprise XML Usage was icky so they needed to completely throw out XML in favor of a much shittier serialization format.

Re: Google did not unilaterally decide to kill XSLT

#82

Post by sugarpimpdorsey »

dkiebd wrote: post #59
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.

> Does it matter whether it will take three months or three years?

Do you think it matters to the guy that said he has an entire factory with IoT machinery that uses XSLT?

Should they shut the factory down?

Re: Google did not unilaterally decide to kill XSLT

#83

Post by wpollock »

mschuster91 wrote: post #49

XML/XSLT is a huge mess of a code base to implement correctly - especially XML parsing has been a fruitful source of exploits in the past. And it's not used in practice these days, it's been ages since I saw that used on the web out of RSS/Atom feeds (which are practically dead, for better or worse) and Java-based CMSes. So from a technical standpoint, I do understand those calling for it to be eventually removed.

>it's been ages since I saw that [XML/XSLT] used on the web out of RSS/Atom feeds (which are practically dead, for better or worse)...

Not dead. I read HN using their feed!

Re: Google did not unilaterally decide to kill XSLT

#84

Post by nashashmi »

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…

The point is to take JS implemented features and make them native to the browser.

Re: Google did not unilaterally decide to kill XSLT

#85

Post by cosmic_cheese »

spankalee wrote: post #68
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

Interesting. Not a bad proposal, but am I reading correctly that partials from a different URL (“includes”) is a someday thing rather than part of the initial spec?

Either way it’d allow several types of sites to have zero dependencies and no build step which is pretty cool.

Re: Google did not unilaterally decide to kill XSLT

#86

Post by bawolff »

ocdtrekkie wrote: post #77
karlgkk wrote: post #53

Earlier quoted context omitted.

> 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

I have yet to find a website which pleasantly lets me download a bunch of things in an efficient and organized manner that compares with FTP. The hilarity of buying a Humble Bundle and pressing "download all" and watching your browser spam "save as" windows for a minute and a half... I kinda wish I could (S)FTP a lot more things than I can today.

Wget? Like this isn't a protocol issue but a website issue. You can do this sort of thing with http just fine.

Re: Google did not unilaterally decide to kill XSLT

#87

Post by bawolff »

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

I think the problem is that people irrationally hate google the way slashdot irrationally hated micro$oft back in the day.

There is really no winning for them. They weren't even the party who proposed removing xslt.

Re: Google did not unilaterally decide to kill XSLT

#88

Post by naniwaduni »

chatmasta wrote: post #37
bawolff wrote: post #5

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. Obligatory: https://xkcd.com/1172/

In this case there is the vocal minority who uses it, and then an even more vocal group who was just reminded XSLT even exists and is protesting its removal on vague ideological grounds. The proposal has clear mitigations for websites or use cases that depend on it, e.g. a WebAssembly polyfill.

The polyfill is a distraction; it does nothing for the use cases in the wild unless it's shipped with the browser, which is basically orthogonal to the spec and in any case Chrome was not willing to do.

Re: Google did not unilaterally decide to kill XSLT

#89

Post by basscomm »

warkdarrior wrote: post #8
hobs wrote: post #4

I like how the resource issue is hand waived away because some random manager decided not to do it, and that's somehow a force of nature now.

People who want that feature to stay in the browsers should put up some money to fund continued development and maintenance.

The problem with this is that it incentivizes browsers to only implement features if it makes them money and to remove everything else.

Re: Google did not unilaterally decide to kill XSLT

#90

Post by bawolff »

_Algernon_ wrote: post #62
arp242 wrote: post #40

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…

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

What do you think happened when HTML was introduced? Its not like html was the only thing trying to do hypertext documents. HTML just happened to win.
Post reply on HN