Live data from Hacker News

Google did not unilaterally decide to kill XSLT

meyerweb.com

101–110 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#101
post #92
post #36

Earlier quoted context omitted.

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.

[flagged]

You can certainly use XSLT with https://www.w3.org/TR/voicexml20/ have you built software on any Linux platform? XSLT is required in so much stuff.

Re: Google did not unilaterally decide to kill XSLT

#102
post #100
post #73

Earlier quoted context omitted.

Okay, so you're saying these people have no credibility to their intentions, and you posit some nefarious alternative motivations for removing XSLT. But you're not saying these people (with no credibility to their intentions) are actually doing this for the alternative nefarious reasons that you mentioned. Ehh... like ... what? You said what you said in that thread. And your "clarification" here adds little nuance to…

[flagged]

[flagged]

Re: Google did not unilaterally decide to kill XSLT

#103

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…

Remember shtml which was supposed to be server side include? It never made it to the web browser.

Re: Google did not unilaterally decide to kill XSLT

#104

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…

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

That's a terrible point.

Re: Google did not unilaterally decide to kill XSLT

#105
post #59
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.

> Since I suppose none of the browser vendors will give developers money to change their xslt usage in codebases for something else.

Let's turn that around: are you willing to pay a browser vendor to keep supporting xslt so you can keep your codebase unchanged?

Re: Google did not unilaterally decide to kill XSLT

#106
post #86

Earlier quoted context omitted.

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.

Can you POST with wget? wput? I should know this...

Re: Google did not unilaterally decide to kill XSLT

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

XSLT is not going away. You can still use it no matter what happens (and it's far from certain something will happen). Browsers are still built on open standards. It just doesn't need to be bundled in every browser by default, similar to BMP as mentioned in the article.

Re: Google did not unilaterally decide to kill XSLT

#108

Earlier quoted context omitted.

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

That's a terrible point.

Not at all. The existence of general purpose scripting isn't and shouldn’t be at odds with equipping HTML to handle a few very common, very basic tasks without JS. There’s plenty to be gained by doing so, including better ergonomics and efficiency. Even heavy JS apps stand to benefit since it’s that much less code to have to write and maintain.

Re: Google did not unilaterally decide to kill XSLT

#109
post #101
post #92

Earlier quoted context omitted.

[flagged]

You can certainly use XSLT with https://www.w3.org/TR/voicexml20/ have you built software on any Linux platform? XSLT is required in so much stuff.

And did you render it in chrome?

Nobody is killing xslt in general, just the web browser bindings.

Re: Google did not unilaterally decide to kill XSLT

#110
post #79

Earlier quoted context omitted.

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?

There's a big difference between removing something to address tech debt in an internal system, or even a normal application, and removing support for a web standard from Google Chrome . It's the single most popular browser on the internet today, so removing support for any given standard from it means, effectively, breaking anything that uses that standard on the web. And because XSLT isn't a particularly user-visib…

Google isn't unilaterally removing XSLT from Chrome. They are participating in a discussion to remove it from the standards first. This would absolutely not be a Chrome-only thing, and so has nothing to do with Chrome marketshare. All the browser vendors are on board here.
Post reply on HN