Earlier quoted context omitted.
[flagged]
[flagged]
[flagged]
Google did not unilaterally decide to kill XSLT
111–120 of 138 posts
Re: Google did not unilaterally decide to kill XSLT
#112Earlier quoted context omitted.
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...
The comment i was responding to was about download not upload.
Certainly though you can do multiple upload on a protocol level in http (resumable upload less so)
Afterall, S3 clients are all http under the hood, and that is basically the defacto standard now.
There certainly exists features in ftp not present in http, but they were rarely used/bad ideas (hello server to server transfer)
Re: Google did not unilaterally decide to kill XSLT
#113XML/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.
I clicked through to this comment section via HN RSS feeds.
Re: Google did not unilaterally decide to kill XSLT
#114Also: It deserved to die
Also also: You hope it burns in hell?
Also also also: Really sorry, it's Pavlovian.
Re: Google did not unilaterally decide to kill XSLT
#115Earlier 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]
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Re: Google did not unilaterally decide to kill XSLT
#116Earlier quoted context omitted.
[flagged]
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html
That's fair.
The better phrased version of my criticism is that voice menus are generally not rendered using a web browser and thus deprecating xslt in web browsers cannot possibly affect them.
Re: Google did not unilaterally decide to kill XSLT
#117I hope that if they decide to update XSLT they'll also implement this:
Re: Google did not unilaterally decide to kill XSLT
#118My 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…
How could #2 possibly be true without it being a deliberate choice on Google's part? They have staggering, absurd amounts of money. If they needed more resources allocated to Chrome, they could just do that.
This is addressed directly in the linked article. "Google" and "the Chrome team" are not the same entity.
Re: Google did not unilaterally decide to kill XSLT
#119Wouldn'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 simp…
The idea is not to just remove things for the sake of removing things, but to engage in a cost-benefit analysis. Most of the things listed above either are very widely used or don't cost much or have other downsides to maintain. By contrast, when things have been removed from the Web platform in the past, it was because they were causing problems out of proportion to the amount of breakage induced by removing them. In the case of XSLT, the problem is the attack surface that it adds.
Re: Google did not unilaterally decide to kill XSLT
#120Earlier 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
It was a quick way to share files. FTP as an internet application made a lot of sense. The only counter reason was it did not have password protections like SFTP did, and did not support encryption. But that is like arguing against HTTP in favor of HTTPS. I don't think they put SFTP in browsers yet.
There was FTPS (FTP+TLS). Not sure if browsers ever supported that but I imagine it’s not too hard to implement iv you have HTTPS already.