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

121–130 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#121

Post by xg15 »

spankalee wrote: post #39

People have had some huge understandings of what's actually going on: - That Mason opening issues means that it's a Google-effort. It's not. - That the "Should we remove..." issue for community feedback. It's not. Spec issues are a collaboration vehicle for spec maintainers. There's not enough of the community on GitHub for that to be a good feedback mechanism. - That Mason or Google hide comments and locked the thre…

A lot of that is irrelevant though. I don't think the problem is that Google might have unilaterally decided this, the problem is that there are unilateral decisions of this kind at all for a tech that affects billions of people.

(And I'm counting agreement between the handful of browser vendors as unilateral decisions as well. The group is not exactly very large)

The second part was basically the author saying "calm down guys, relax, there is a process." - and then speculating what that process might be.

If there is an orderly, public process that is being followed here, that includes a time and place for community feedback, shouldn't you be able to read up on it somewhere instead of speculating?

Re: Google did not unilaterally decide to kill XSLT

#122

Post by [deleted] »

nashashmi wrote: post #75
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

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.

[deleted]

Re: Google did not unilaterally decide to kill XSLT

#123

Post by Springtime »

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…

Some of the things that stood out to me about the news:

- The thread by the Chromium dev proposed what was originally a 1MB minified polyfill for the Javascript only XSLT calls that in just the last few days has grown to 3MB minified. XSLT was beneficial in the browser because it was native, while a 3MB polyfill is a rather big ask to suggest as a per-site replacement for anything meant to be snappy on slower connections.

- It seems from various mentions the catalysts for this to surface now were the sole maintainer for the XSLT library used in Chromium expressed having trouble maintaining it some months back and left it to a different sole maintainer, along with a recently disclosed vulnerability in that particular library. Firefox OTOH is said to use a different XSLT library.

- Chromium team routinely awards vulnerability discovery bounties in the tens to hundreds of thousands of dollars. Just the other week they awarded $250k to an author who discovered a tricky Chromium exploit. I'd be curious if they've funded development of the XSLT library they use in the past as it seems like they'd rather just be rid of it.

- Within days of posting the open question to the working group and a week prior to the PR of the spec removal a Chromium ticket by the author set milestones for XSLT removal in Chromium. It seems it's less a tentative proposal and more leading by example.

Re: Google did not unilaterally decide to kill XSLT

#124

Post by Klonoar »

spankalee wrote: post #70
worble wrote: 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.

Removing Flash, Mutation Events, and third-party cookies broke websites.

Look man, Flash was not the same thing and people need to stop bringing this up.

Flash was a third party plugin that got way out of hand. It wasn’t (necessarily) the job the browser vendors created for themselves and offered for years.

Flash was also moreso removed on a fledgling platform first that grew to be a dominant platform; it wasn’t killed off on an existing dominant platform first.

Re: Google did not unilaterally decide to kill XSLT

#125

Post by chrismorgan »

nashashmi wrote: post #80
spankalee wrote: post #74

Earlier quoted context omitted.

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

Firefox and Chromium had in-built FTP protocol handlers. I believe extensions could depend on this in such a way that the removal might break things for them, but general web content couldn’t—it was just an external link.

Safari and IE didn’t have integrated FTP: rather, they could hand FTP links over to the OS for something outside the browser to handle.

Now Firefox and Chromium can hand FTP over to the OS too.

XSLT, on the other hand, is integrated, a true part of the web platform. XSLTProcessor on any page, on XML files loaded directly… it works everywhere. The case is quite different from FTP.

If they remove XSLT, this will be the first time a major baseline-available feature has been removed. (One or two minor features have been removed: SharedArrayBuffer was temporarily dropped very shortly after landing across the board, for solid security reasons, taking up to 4 years to return with suitable limitations; and mutation events came in 2011 before quickly being replaced with mutation observers in 2012–2013, finally being removed in the last year or so; and the unload event which has been known to be unreliable and a bad idea for at least a decade is in the process of being removed. But all three of these are likely to be very minor in their effects, where XSLT removal just breaks your entire page.)

Re: Google did not unilaterally decide to kill XSLT

#126

Post by thro1 »

Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )

Just Firefox XSLT is faster, better than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox.

JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like having open issues" ).

Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free.

Re: Google did not unilaterally decide to kill XSLT

#127

Post by lenkite »

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.

I wish there was a way to fund XSLT feature in browsers. Chrome team should just open up a funding for features page.

Re: Google did not unilaterally decide to kill XSLT

#128

Post by riedel »

xg15 wrote: post #121
spankalee wrote: post #39

People have had some huge understandings of what's actually going on: - That Mason opening issues means that it's a Google-effort. It's not. - That the "Should we remove..." issue for community feedback. It's not. Spec issues are a collaboration vehicle for spec maintainers. There's not enough of the community on GitHub for that to be a good feedback mechanism. - That Mason or Google hide comments and locked the thre…

A lot of that is irrelevant though. I don't think the problem is that Google might have unilaterally decided this, the problem is that there are unilateral decisions of this kind at all for a tech that affects billions of people. (And I'm counting agreement between the handful of browser vendors as unilateral decisions as well. The group is not exactly very large) The second part was basically the author saying "calm…

I would agree to see the outcry more as a symptom about this meritocratic system. I think we are at a point where new browser/rendering engines are developing like ladybird or Servo. An independent group should make sure that they will strive. Making specs simpler can help here. But I think many things are done for the wrong reasons (E.g. Google wanting to cut down cost on parts irrelevant to their income, other vendors that are reliant on them).

Last time I used XSLT in the browser was actually transforming PMML to JavaScript executable ML models about 10 yrs ago. Before that I think it was building a light weight web frontend for our SVN repo. With XML APIs replaced by json or binary formats, the relevance is becoming less and less. And in the end it is about legacy stuff only because there are XSLT compilers [0] that could fill the gap (maybe with a small web extension, that won't work on phones with native Apple and Google browsers...)

[0] https://github.com/egh/xjslt

Re: Google did not unilaterally decide to kill XSLT

#129

Post by xg15 »

riedel wrote: post #128
xg15 wrote: post #121

Earlier quoted context omitted.

A lot of that is irrelevant though. I don't think the problem is that Google might have unilaterally decided this, the problem is that there are unilateral decisions of this kind at all for a tech that affects billions of people. (And I'm counting agreement between the handful of browser vendors as unilateral decisions as well. The group is not exactly very large) The second part was basically the author saying "calm…

I would agree to see the outcry more as a symptom about this meritocratic system. I think we are at a point where new browser/rendering engines are developing like ladybird or Servo. An independent group should make sure that they will strive. Making specs simpler can help here. But I think many things are done for the wrong reasons (E.g. Google wanting to cut down cost on parts irrelevant to their income, other vend…

Yeah, I was surprised so many people were caring about XSLT. As a language it really isn't very good and I wasn't aware it was used in a meaningful fashion at all.

(Still, it always felt like a glimpse into an alternative, much less hackish processing model for the web, where you just have DOM trees and a pipeline of pure functions to transform them into different trees. I think that approach is still worth exploring and a lot of more recent tech, like React does it)

But I feel the backlash is more a symptom of how the web platform is ran in general.

Re: Google did not unilaterally decide to kill XSLT

#130

Post by 6510 »

ameliaquining wrote: post #119
6510 wrote: post #54

Earlier quoted context omitted.

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

Reading online for a bit it seems cors already ruined much of the fun. If you think about it, even with the "*" header you end up with a html document served from a different place than the url would suggest.

Kinda sad since slapping a generic template onto some familiar xml implementation seems a wonderful thing.

I've always wanted browsers to provide a set of standard templates. 90% of the time I don't care about the design, I just want something functional right now.

Post reply on HN