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]
Google did not unilaterally decide to kill XSLT
101–110 of 138 posts
Re: Google did not unilaterally decide to kill XSLT
#102Earlier 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]
Re: Google did not unilaterally decide to kill XSLT
#103I 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…
Re: Google did not unilaterally decide to kill XSLT
#104Earlier 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.
Re: Google did not unilaterally decide to kill XSLT
#105My 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.
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
#106Earlier 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.
Re: Google did not unilaterally decide to kill XSLT
#107Earlier 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…
Re: Google did not unilaterally decide to kill XSLT
#108Earlier quoted context omitted.
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
#109Earlier 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.
Nobody is killing xslt in general, just the web browser bindings.
Re: Google did not unilaterally decide to kill XSLT
#110Earlier 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…