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

91–100 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#91

Post by bawolff »

ocdtrekkie wrote: post #19
_bzuf wrote: post #12

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. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.

This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours , not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. One of the things I learned about Google during the AMP4Email fiasco is that the st…

> they need to provide a clear venue for people to indicate whether or not the community is accepting of a change.

The venue is the right to fork.

The standard is made by people who write code implementing web browsers. Rando freeloaders who don't put in the work don't get a vote.

This is how the internet has always worked, to pataphrase a different standards body - running code and loose consensus.

Re: Google did not unilaterally decide to kill XSLT

#92

Post by bawolff »

th0ma5 wrote: post #36
samdoesnothing wrote: post #29

Earlier quoted context omitted.

> while they destroy the web Don't you think you're being a little bit dramatic? The chances of anybody who isn't an ubernerd caring about XSLT's removal is exactly 0.

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]

Re: Google did not unilaterally decide to kill XSLT

#93

Post by goyagoji »

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 find it bizarre. I think we obviously we want to be able to run pages from 2015 far in the future but certainly for a few more years.

As a browser maker, why would you even put this work in for cordinated processes instead of investing in a way to patch away your native code and do that continuously at a slow pace for every aging feature?

Re: Google did not unilaterally decide to kill XSLT

#94

Post by bawolff »

chatmasta wrote: post #37
bawolff wrote: post #5

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. Obligatory: https://xkcd.com/1172/

In this case there is the vocal minority who uses it, and then an even more vocal group who was just reminded XSLT even exists and is protesting its removal on vague ideological grounds. The proposal has clear mitigations for websites or use cases that depend on it, e.g. a WebAssembly polyfill.

I dont think the web assembly is a great polyfill, at least for the <?xml-stylesheet processing instruction. The better alternative is to just use CSS which is powerful enough for most real usecases.

Re: Google did not unilaterally decide to kill XSLT

#95

Post by bawolff »

yjftsjthsd-h wrote: post #16
bawolff wrote: post #5

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. Obligatory: https://xkcd.com/1172/

> I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. As opposed to non-OSS, where removing features that paying customers care about is of course trivial? > Obligatory: https://xkcd.com/1172/ I don't mindless comic and its or…

> As opposed to non-OSS, where removing features that paying customers care about is of course trivial?

When the amount they are paying you is much less then the amount it costs to maintain it is, then yes it is usually fairly easy.

Re: Google did not unilaterally decide to kill XSLT

#96

Post by [deleted] »

bawolff wrote: post #87
_bzuf wrote: post #12

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. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.

I think the problem is that people irrationally hate google the way slashdot irrationally hated micro$oft back in the day. There is really no winning for them. They weren't even the party who proposed removing xslt.

[deleted]

Re: Google did not unilaterally decide to kill XSLT

#97

Post by basscomm »

paulsutter wrote: post #46

Is there any reason this cant be solved with a proxy server? So that legacy software that uses XLST can still run on the new browsers that lack it? XLST is a really weird feature and it seems sensible to drop it, be nice if there is a transparent solution for old software that uses it.

> Is there any reason this cant be solved with a proxy server? So that legacy software that uses XLST can still run on the new browsers that lack it?

With XSLT in a browser I can throw some static XML and XSLT files on any web server and they will Just Work™ and be usable without me having to do much other than telling the web server to serve index.xml instead of index.html. If I have to learn how to set up and maintain a proxy server so visitors to my site can still view the rendered pages, then I probably won't bother.

> XLST is a really weird feature and it seems sensible to drop it

What's weird about it? It lets me mark up some text using whatever XML makes sense to me and then write a template that the browser uses to transform it into (X)HTML that it can display. For someone who builds basic sites, it's an easy way to do templating that doesn't involve me setting up a 'real' programming environment

Re: Google did not unilaterally decide to kill XSLT

#98

Post by dang »

Related ongoing thread:

Should the web platform adopt XSLT 3.0? - https://news.ycombinator.com/item?id=44987552

Recent and also related:

XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 - Aug 2025 (99 comments)

"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (523 comments)

Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)

Re: Google did not unilaterally decide to kill XSLT

#99

Post by yjftsjthsd-h »

bawolff wrote: post #95
yjftsjthsd-h wrote: post #16

Earlier quoted context omitted.

> I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. As opposed to non-OSS, where removing features that paying customers care about is of course trivial? > Obligatory: https://xkcd.com/1172/ I don't mindless comic and its or…

> As opposed to non-OSS, where removing features that paying customers care about is of course trivial? When the amount they are paying you is much less then the amount it costs to maintain it is, then yes it is usually fairly easy.

I wish my career had entirely comprised of as functional of companies as you seem to work in.

Re: Google did not unilaterally decide to kill XSLT

#100

Post by _bzuf »

arp242 wrote: post #73
_bzuf wrote: post #61

Earlier quoted context omitted.

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…

[flagged]
Post reply on HN