Ah, the corporate enshittification ensues.
"Remove mentions of XSLT from the html spec"
501–510 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#502Earlier quoted context omitted.
I'd love to see more powerful HTML templating that'd be able to handle arbitrary XML or JSON inputs, but until we get that, we'll have to make do with XSLT. For now, there's no alternative that allows serving an XML file with the raw data from e.g. an embedded microcontroller in a way that renders a full website in the browser if desired. Even more so if you want to support people downloading the data and viewing it…
If you're OK with the startup cost of 2-3 more files for the viewer bootstrap, you could just fetch the XML data from the microcontroller using JS. I assume the xsl stylesheet is already a separate file.
I don't think anyone is attached to the technology of xslt itself, but to the UX it provides.
Your microcontroller only serves the actual xml data, the xslt is served from a different server somewhere else (e.g., the manufacturer's website). You can download the .xml, double-click it, and it'll get the xslt treatment just the same.
In your example, either the microcontroller would have to serve the entire UI to parse and present the data, or you'd have to navigate to the manufacturers website, input the URL of your microcontroller, and it'd have to do a cors fetch to process the data.
One option I'd suggest is instead of
The service worker would not be associated with any specific origin, but it would still receive the regular lifecycle of events, including a fetch event for every load of an xml document pointing at this specific service worker script.
Using https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/... it could respond to the XML being loaded with a transformed response, allowing it to process the XML similar to an XSLT.
You could even have a polyfill service worker that loads an XSLT and applies it to the XML.
Re: "Remove mentions of XSLT from the html spec"
#503Earlier quoted context omitted.
This is breaking the web though. If they are so worried, then have the xslt support compiled to wasm and sandboxed.
This is not breaking the web , stop being so needlessly hyperbolic. XSLT use is absolutely tiny. If you removed it, >99.9% of the web wouldn’t even notice.
If we removed everyone named Jim Dabell from the world, the other 99% wouldn't even notice. They're absolutely tiny. Perhaps we should try doing that.
Re: "Remove mentions of XSLT from the html spec"
#504Earlier 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…
>while there was enormous energy to improve JavaScript What was the point of it though? People transpile from other languages anyway and pull megabytes of npm dependencies.
This question in analogous to what is the point of better CPUs when people use compilers/assemblers instead of writing binaries in an hex editor.
Re: "Remove mentions of XSLT from the html spec"
#505Earlier quoted context omitted.
This is not breaking the web , stop being so needlessly hyperbolic. XSLT use is absolutely tiny. If you removed it, >99.9% of the web wouldn’t even notice.
If we removed everyone named Jim Dabell from the world, the other 99% wouldn't even notice. They're absolutely tiny. Perhaps we should try doing that.
It certainly wouldn’t break the world. You are being needlessly hyperbolic.
Re: "Remove mentions of XSLT from the html spec"
#506Earlier quoted context omitted.
I think this post is useful where the thread author proposed some solutions to the people affected: https://github.com/whatwg/html/issues/11523#issuecomment-318... The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering. I think this could be addressed by introducing a processing instruction that browsers would inter…
Any solution that requires any change to the websites affected, no matter how small, is not a solution at all. DO. NOT. BREAK. THE. WEB.
Ah how easy is it to bloviate when you're not actually the one having to maintain the web, huh?
Re: "Remove mentions of XSLT from the html spec"
#507Earlier quoted context omitted.
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.
Ah, gotcha. Thanks for that. Ok, I could see why that’d be smaller, although I wonder now much compression could equalize it.
Re: "Remove mentions of XSLT from the html spec"
#508Re: "Remove mentions of XSLT from the html spec"
#509Earlier quoted context omitted.
First, we are an insignificant portion of the web, and it's okay to admit that. Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.
It's not OK for the Google & co to chip away at "insignificant" portions of the web until all that's left are big corporate run platforms.
First, you're assuming that those portions of the Web won't evolve in order to survive. Second, you're ascribing a motive to Google that you assume (probably falsely) that they possess.
Re: "Remove mentions of XSLT from the html spec"
#510Earlier 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/
Do you honestly believe none of these will be addressed before the deadline passes?