"Remove mentions of XSLT from the html spec" • Hacker News Board

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

#111

Post by JimDabell » Tue, Aug 19, 2025, 4:15 PM UTC

Y_Y wrote: post #19

> @whatwg whatwg locked as too heated and limited conversation to collaborators Too heated? Looked pretty civil and reasonable to me. Would it be ridiculous to suggest that the tolerance for heat might depend on how commenters are aligned with respect to a particular vendor?

> Why do people create such joke PRs?

> We didn't forgot your decade of fuckeries, Google.

> You wanted some heated comment? You are served.

> the JavaScript brainworm that has destroyed the minds of the new generation

> the covert war being waged by the WHATWG

> This is nothing short of technical sabotage, and it’s a disgrace.

> breaking yet another piece of the open web you don't find convenient for serving people ads and LLM slop.

> Are Google, Apple, Mozilla going to pay for the additional hosting costs incurred by those affected by the removal of client-side XSLT support?

> Hint: if you don't want to be called out on your lies, don't lie.

> Evil big data companies who built their business around obsoleting privacy. Companies who have built their business around destroying freedom and democracy.

> Will you side with privacy and freedom or will you side with dictatorship?

Bullshit like this has no place in an issue tracker. If people didn’t act like such children in a place designed for productive conversation, then maybe the repo owners wouldn’t be so trigger happy.

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

#112

Post by lucb1e » Tue, Aug 19, 2025, 4:15 PM UTC

troupo wrote: post #63

lucb1e wrote: post #32

I had no idea what XSLT even was until today. Reading the submission, the thread linked by u/troupo below, and Wikipedia, I find that it's apparently used in RSS parsing by browsers, because RSS is XML and then XSLT is "originally designed for transforming XML documents into other XML documents" so it can turn the XML feed into an HTML page I agree RSS parsing is nice to have built into browsers. (Just like FTP suppo…

> I also don't really understand the complaint from the Chrome people that are proposing it: "it's too complex, high-profile bugs, here's a polyfill you can use". Especially considering the amount of complex standards they have qualms about from WebUSB to 20+ web components standards > On the other hand, I don't normally view RSS feeds manually. Chrome metrics famously underrepresent corporate installation. There cou…

We pentest lots of corporate applications so if this was widespreadly deployed in the last ~8 years that I've been doing the job full time, I don't know how I would have missed it (like, never even saw a talk about it, never saw a friend using it, never heard a colleague having to deal with it... there's lots of opportunities besides getting such an assignment myself). Surely there are talks on it if you look for it, just that I haven't the impression that this is a common corporate thing, at least among the kinds of customers we have (mainly larger organizations). A sibling comment mentions they use it on their hobby site though

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

#113

Post by BoiledCabbage » Tue, Aug 19, 2025, 4:16 PM UTC

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 mostly ignored.

And "if this is about adoption then listen to the constant community request to update the the newer XSLT 3.0 which has been out for years and world have much higher adoption due to tons of QoL improvements including handling JSON."

And the argument presented, which i don't know (but seems reasonable to me), is that XSLT supports the open web. Google tried to kill it a decade ago, the community pushed back and stopped it. So Google's plan was to refuse to do anything to support it, ignore community requests for simple improvements, try to make it wither then use that as justification for killing it at a later point.

Forcing this through when almost all feedback is against it seems to support that to me. Especially with XSLT suddenly/recebtly gaining a lot of popularity and it seems like they are trying to kill it before they have an open competitor in the web.

https://github.com/whatwg/html/issues/11523

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

#114

Post by dehrmann » Tue, Aug 19, 2025, 4:16 PM UTC

codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

> Why should the browser contain a specific template engine, like XSLT, and not Jinja for example?

Historic reasons, and it sounds like they want it to contain zero template engines. You could transpile a subset of Jinja or Mustache to XSLT, but no one seems to do it or care.

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

#115

Post by geocar » Tue, Aug 19, 2025, 4:17 PM UTC

ameliaquining wrote: post #71

ksec wrote: post #40

Do we know Webkit, KHTML and Gecko's stand on this? I know this is for security reason but why not update the XSLT implementation instead. And if feature that aren't used get dropped, they might as well do it all in one good. I am sure lots of HTML spec aren't even used.

WebKit's in favor: https://github.com/whatwg/html/issues/11523#issuecomment-314...

"Cautiously" in favour.

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

#116

Post by JimDabell » Tue, Aug 19, 2025, 4:18 PM UTC

codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

> Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM.

I think a dedicated unsupported media type -> supported media type WASM transformation interface would be good. You could use it for new image formats and the like as well. There are things like JXL.js that do this:

https://github.com/niutech/jxl.js

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

#117

Post by kg » Tue, Aug 19, 2025, 4:19 PM UTC

4ndrewl wrote: post #72

lucb1e wrote: post #32

I had no idea what XSLT even was until today. Reading the submission, the thread linked by u/troupo below, and Wikipedia, I find that it's apparently used in RSS parsing by browsers, because RSS is XML and then XSLT is "originally designed for transforming XML documents into other XML documents" so it can turn the XML feed into an HTML page I agree RSS parsing is nice to have built into browsers. (Just like FTP suppo…

XSLT was the blockchain, nft, metaverse of the mid?-2000s. Was totally going to solve all of our problems.

At the time I ran across lots of real websites using it. I successfully used it myself at least once too. Off the top of my head, Blizzard was using it to format WoW player profiles for display in the browser.

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

#118

Post by kg » Tue, Aug 19, 2025, 4:20 PM UTC

nikeee wrote: post #94

If security and memory-safety is a concern and there is already a polyfill, why remove the API form the standard instead of just using the WASM-based polyfill internally?

They want to punt a half-baked polyfill over the wall and remove support from the browser so they don't have to do any maintenance work, making it someone else's problem.

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

#119

Post by brian_herman » Tue, Aug 19, 2025, 4:20 PM UTC

As long as xpath is still there I approve

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

#120

Post by codedokode » Tue, Aug 19, 2025, 4:21 PM UTC

_ache_ wrote: post #102

codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

I get the point a minimal browser and WASM, but Java bytecode ?! Why not Python bytecode ? Seems unreasonable to me to add any specific bytecode support. By layout rules you mean get rid of CSS ? Sounds also unreasonable IMHO. And no WebAudio and Canvas couldn't be implemented in client WASM without big security implication. If by module you mean inside the browser, them, what is the point of WASM here ?

What WebAudio needs to provide is only means to get or push buffers from/to audio devices and run code in high priority thread. There is no need for browser to provide implementation of low-pass filters, audio proccessing graphs and similar primitives.