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]
"Remove mentions of XSLT from the html spec"
451–460 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#452Earlier 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
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"
#453Earlier 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/
Before calling people arrogant you should read your own links.
[The congress example is legit]
Re: "Remove mentions of XSLT from the html spec"
#454So 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.
Re: "Remove mentions of XSLT from the html spec"
#455> @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 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"
#456Earlier quoted context omitted.
[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"
#457Earlier 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?
Re: "Remove mentions of XSLT from the html spec"
#458It'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 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."
Re: "Remove mentions of XSLT from the html spec"
#459Earlier 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.
Re: "Remove mentions of XSLT from the html spec"
#460Earlier 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.