Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

451–460 of 559 posts

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

#451
post #348

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…

[flagged]

The vast majority of feedback on the GitHub issue was respectful — unless you consider opposing the proposal disrespectful.

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

#452
post #445

Earlier quoted context omitted.

I secondly doubt this. Would love a succinct list of "important" websites.

Do Library of Congress and Congress count? https://news.ycombinator.com/item?id=44958929 It's not for the public to identify these sites. It's for the arrogant Googlers to do a modicum of research

At first glance the library of congress link appears to be using server side XSLT, which would not be affected by this proposal.

The congress one appears to be the first legit example i have seen.

At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.

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

#453
post #441

Earlier quoted context omitted.

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?

This was mentioned in the discussions and are an easy search away. Which means that googlers in their arrogance didn't do any research at all and that their counter underrepresents data as explicitly stated in their own document https://www.loc.gov/standards/mods/mods-conversions.html https://www.loc.gov/preservation/digital/formats/fdd/fdd_xml... And then there's Congress: https://simonwillison.net/2025/Aug/19/xslt/

The library of congress examples appear to be using server side xslt not client side. Thus they are not affected by this deprecation.

Before calling people arrogant you should read your own links.

[The congress example is legit]

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

#454

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.

Not really, because that would add a dependency on Javascript whereas, at the moment, XSLT works without Javascript enabled.

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

#455
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?

I disagree - I saw a number of comments I would consider rude and unprofessional and once a PR gets posted on HN, frankly it typically gets much worse.

I find people on HN are often very motivated reasoners when it comes to judging civility, but there’s basically no excuse for calling people “fuckers” or whatever.

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

#456
post #348

Earlier quoted context omitted.

[flagged]

The vast majority of feedback on the GitHub issue was respectful — unless you consider opposing the proposal disrespectful.

There’s not nearly enough comments for “vast majority” to be a useful descriptor, and I saw a significant number of uncivil, rude comments.

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

#457
post #398

Earlier quoted context omitted.

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.

That’s fascinating because I wouldn’t have expected it. What’s an example of when they rendered output would be bigger?

Imagine 1000 numbers in XML and a XSLT with xsl:for-each which renders a div with a label, textbox with the number and maybe a button. That's a simple example. Output would be a lot longer than XML+XSLT.

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

#458
post #246

It's not like the browsers can just switch to some better maintained XSLT library. There aren't any. There are about 1.5 closed-source XSLT 3 implementations, Altova and Saxonica. I don't want to sound ageist, but the latter is developed by the XSLT spec's main author, who is nearing retirement age. This library is developed behind closed doors, and from time to time zip files with code get uploaded to GitHub. Make o…

Saxonica is an Employee Ownership Trust and the team as a whole is relatively young (far off from retirement).

"Saxonica today counts some of the world's largest companies among its customer base. Several of the world's biggest banks have enterprise licenses; publishers around the world use Saxon as a core part of their XML workflow; and many of the biggest names in the software industry package Saxon-EE as a component of the applications they distribute or the services they deploy on the cloud."

https://www.saxonica.com/about/about.xml

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

#459
post #412
post #378

Earlier quoted context omitted.

WHATWG broke this quasi-officially when they declared HTML a "Living Standard". The HTML spec is not a standard to be implemented anymore, it's just a method of coordinating/announcing what the browser vendors are currently working on. (For the same reason, they dropped the name HTML5 and are only talking about "HTML". Who needs version numbers if there is no future and no past anyway?) https://whatwg.org/faq#living-…

Your FAQ stresses the importance of backwards compatibility multiple times. Seems hard to square removing XSLT with that.

Yeah, that was my impression about their process. They replaced formalized compatibility guarantees through versions with "trust me, bro".

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

#460
post #86
post #47

Earlier quoted context omitted.

No, that would indeed be reasonable, but the proposal is to remove XSLT from the standard and remove Chrome support for XSLT entirely, forcing websites to adopt the polyfill themselves.

Which is, to me, silly. If you ship the polyfill then there's no discussion to be had. It works just the same as it always has for users and it's as secure as V8, no aging native codebase with memory corruption bugs to worry about.

At the moment, XSLT in a browser doesn't depend on Javascript, so works even if JS is turned off. Using a polyfill instead will mean that XSLT will only work if JS is turned on.
Post reply on HN