Live data from Hacker News

Google did not unilaterally decide to kill XSLT

meyerweb.com

71–80 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#71
post #65

I do not understand how this can possibly be considered. It comes down to one question: will this break websites that are in production right now? If the answer is yes then it can't be done, simple as. I really don't care about anything else, you can't just break the web for people who are actively using it.

I mean, of course they can. They're Google. What are you going to do, stop using Chrome and searching with Google and using Gmail and buying AdWords and....etc?

This is what happens when you have a monopoly.

Re: Google did not unilaterally decide to kill XSLT

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

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.

Re: Google did not unilaterally decide to kill XSLT

#73
post #61
post #50

Earlier quoted context omitted.

Mate ... Your full comment: "XSLT isn't a tool for surveillance capitalism, nor for glossy product brochure presentation, nor for captive passive doomscrolling video experiences, so it must be actively excised from the global knowledge network hypermedia standard" If that's not saying "they're doing it because [..]" then I don't know what it's saying.

I made my point more clear in this later comment thread, in which we are talking, where I said: > 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. There is a long history of conflicts of interest in Web standards (de jure and de facto), and my point is that regardless of the merits of removing XSLT there's a…

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

Re: Google did not unilaterally decide to kill XSLT

#74

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…

FTP was not torn down just because some web browsers stopped also being FTP clients. You can still use any FTIP client with any FTP server that you want.

Re: Google did not unilaterally decide to kill XSLT

#75
post #53

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

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.

Re: Google did not unilaterally decide to kill XSLT

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

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

It does!

I run a small hobby site built with XML and XSLT because I'm not a great programmer, but XSLT is something I can actually wrap my head around and use without too much fuss. If support goes away I need to know how much time I have to rewrite/migrate my site to something else.

Re: Google did not unilaterally decide to kill XSLT

#77
post #53

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

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.

Re: Google did not unilaterally decide to kill XSLT

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

> Funny that we are talking about "info that leaks to the public"

It's a poor choice of words by the GP. This was a public discussion, what would be private about it?

Rather it "leaked" from people with shared context to people without it. The point of the article is that since the discussion is public, there will be people that come across it without context, so it would be a good idea to include context in these kinds of discussions in the future:

> If a removal discussion is going to be held in public, then it should assume the general public will see it and provide enough context for the general public to understand the actual nature of the discussion.

Re: Google did not unilaterally decide to kill XSLT

#79

Earlier quoted context omitted.

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?

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-visible standard, there's no easy way to tell which websites will use it, and any website that breaks because of it will just appear not to be supporting Chrome, rather than the other way around. (Flash, for instance, was a much more visible feature, and it was generally very clear when a website broke because it was using Flash when support went away. Plus, of course, it was not a web standard.)

Re: Google did not unilaterally decide to kill XSLT

#80

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…

FTP was not torn down just because some web browsers stopped also being FTP clients. You can still use any FTIP client with any FTP server that you want.

But it was torn down from the browser. That’s what we are talking about with respect to XSLT
Post reply on HN