Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

Post reply on HN
Print view View original

391–400 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#391

Post by em-bee »

jerf wrote: post #333
xg15 wrote: post #318

Earlier quoted context omitted.

That's not completely wrong, but also misses some nuance. E.g. the thread mentions the fact that web support is still stuck at XSLT 1.0 as a reason for removal. But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript. I don't want to imply that if they had just added support for XSLT 3.0 then ev…

Javascript was instantly a hit from the day it was released, and it grew from there. XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player. There was, at no point, any reason to invest in it any farther. Moreover, even if you pu…

i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.

Re: "Remove mentions of XSLT from the html spec"

#392

Post by fancyfredbot »

codedokode wrote: post #375
Pxtl wrote: post #335

So Google is bringing the deprecation treadmill to the web, yay! Yegge called it: https://steve-yegge.medium.com/dear-google-cloud-your-deprec... """ > Because I sometimes get similar letters from the Google Cloud Platform. They look like this: >> Dear Google Cloud Platform User, >> We are writing to remind you that we are sunsetting [Important Service you are using] as of August 2020, after which you will not be abl…

But if you live in a capitalist country with a free market, several competitors should pop out and suggest migrating your system into their cloud for free, shouldn't they? No way capitalist overlooks an unoccupied market niche.

Oh look over there, is that Azure?

Re: "Remove mentions of XSLT from the html spec"

#393

Post by troupo »

spankalee wrote: post #92

A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…

> Even so, give the cross-vendor support for this is seems likely to proceed at some point.

Yup. Just like the removal of confirm/prompt that had vendor support and was immediately rushed. Thankfully to be indefinitely postponed.

Here's Google's own doc on how a feature should be removed: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...

Notice how "unilateral support by browser vendors" didn't even look at actual usage of XSLT, where it's used, and whether significant parts would be affected.

Good times.

Re: "Remove mentions of XSLT from the html spec"

#394

Post by bilog »

webstrand wrote: post #191
BoiledCabbage wrote: post #113

So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all m…

It would be incredible if we could pull it into the javascript/wasm sandbox and get xslt 3.0 support. The best of both worlds, at the cost of a performance hit on those pages, but not a terrible cost.

There's even a JS implementation of XSLT 3.0 already (SaxonJS).

Re: "Remove mentions of XSLT from the html spec"

#395

Post by youngtaff »

em-bee wrote: post #391
jerf wrote: post #333

Earlier quoted context omitted.

Javascript was instantly a hit from the day it was released, and it grew from there. XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player. There was, at no point, any reason to invest in it any farther. Moreover, even if you pu…

i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.

How do you format a raw XML file in the browser without XSLT?

Re: "Remove mentions of XSLT from the html spec"

#396

Post by otterley »

troupo wrote: post #381
otterley wrote: post #145

Earlier quoted context omitted.

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

1. Chrome telemetry underreports a lot of use cases 2. They have a semi-internal document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... that explicitly states: small usage percentage doesn't mean you can safely remove a feature --- start quote --- As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in…

Hmm, I don't see the LOC listed here among the top sites: https://chromestatus.com/metrics/feature/timeline/popularity... - where are you seeing the Library of Congress as impacted?

Re: "Remove mentions of XSLT from the html spec"

#397

Post by otterley »

ndriscoll wrote: post #350
jerf wrote: post #303

Earlier quoted context omitted.

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize…

Statistically, how many websites are using webusb? I'm guessing fewer than xslt, which is used by e.g. the US Congress website. I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component sys…

Where is the US Congress's website identified as a potentially impacted site? https://chromestatus.com/metrics/feature/timeline/popularity...

edit: I see Simon mentioned it - https://simonwillison.net/2025/Aug/19/xslt/ - e.g., https://www.congress.gov/119/bills/hr3617/BILLS-119hr3617ih.... - the site seems to be even less popular than Longhorn Steakhouse in Germany.

My guess is that they'll shuffle people to PDF or move rendering to the server side, which is a common (and, with today's computing power, extremely cheap) way to generate HTML from XML.

Re: "Remove mentions of XSLT from the html spec"

#398

Post by bilog »

kstrauser wrote: post #284
geocar wrote: post #175

Earlier quoted context omitted.

> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations. Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio... > and not Jinja for example? Jinja operates on text, so it's basically document.w…

I'm asking this genuinely, not as a leading question or a gotcha trap: why use this client side, instead of running it on the server and sending the rendered output?

For one, in many cases the XML + XSLT is more compact than the rendered output, so there are hosting and bandwidth benefits, especially if you're transforming a lot of XML files with the same XSLT.

Re: "Remove mentions of XSLT from the html spec"

#399

Post by bawolff »

const_cast wrote: post #371
bawolff wrote: post #349

Earlier quoted context omitted.

[Citation needed] Seriously, i doubt this.

A lot of very old SPA like heavy applications use XSLT. Basically, enterprise web applications (not websites) that predate fetch, rest, and targeted or still target Internet Explorer 5/6. There was a time where the standard way to build a highly interactive SPA was using SOAP services on the backend combined with iframes on the front end that executed XSLT in the background to update the DOM. Obviously such an approa…

> Internet Explorer 5/6

Afaik IE 5 did not support XSLT. It supported a proprietary similar language that was different. I think IE6 was first version to support XSLT.

I feel like when i see enterprise xslt a lot of it is serverside.

Re: "Remove mentions of XSLT from the html spec"

#400

Post by geocar »

adwn wrote: post #302
geocar wrote: post #178

Earlier quoted context omitted.

> [0] ~0.001% usage according to one post there This is still a massive number of people who are going to be affected by this. https://news.ycombinator.com/item?id=44938747

I get what you're saying, but following this line of reasoning would mean that successful, wide-spread specifications, standards, and technologies must never drop any features. They would only ever accumulate new features, bloating to the point of uselessness, and die under the weight of their own success.

Nonsense. Following this line of reasoning is that putting percentages on billions is intellectually dishonest: You don't have to go any further than that. It is perhaps out of ignorance (now you know), but if you try to make it about anything else, that's just arguing in bad-faith.

Of course you can drop features, but if you work at Google I think you can pick something else, and you'll have a hard time convincing anyone that XSLT which was in Chrome back when it was fast, is why Chrome isn't fast anymore. And if you don't work at Google, why do you care? You've learned something new today. Enjoy.

Post reply on HN