Show HN: JavaScript-free (X)HTML Includes
31 comments
·August 22, 2025xnx
Why didn't HTML imports stick around? https://web.dev/articles/imports
lloydatkinson
The moronic Web Component cabal got their hands on it and trashed it by forcing it to rely on JavaScript, thus ensuring it would never get support.
abraham
For a long time web components generally built on four standards:
- Custom HTML elements
- Shadow DOM
- HTML imports
- HTML templates
Eventually it became clear some browsers were not going to implement and the design of HTML imports was better handled be ES modules.
https://webmasters.stackexchange.com/questions/127482/on-wha...
bawolff
Since this seems to be about the recent proposal to remove xslt, i'd point out you can do the same thing with CSS
https://bawolff.net/css-website/index.xml is Evidlo's example but using a css stylesheet instead of xslt. I changed some of the text to explain what i was doing, but otherwise the XML is unchanged with one exception. Unfortunately you do have to put the <a> tags in the xhtml namespace to make them clickable. Other than that no changes to the xml.
Obviously there is a lot that xslt can do that css cannot, but when it comes to just display, CSS is an option here.
shakna
As of the next version of Chrome, XSLT will be gated behind a flag.
Google have also asked for it to be removed from the standard [0].
chrismorgan
> As of the next version of Chrome, XSLT will be gated behind a flag.
Citation? That would greatly surprise me in its abruptness and severity (they only just started talking about it this month, and acknowledge it’s particularly risky for enterprise) and https://chromestatus.com/feature/4709671889534976 gives no such indication.
shakna
The meeting referenced there, from March not last month, also gives no indication that they'd go ahead and make any moves - "stick a pin in it". But they did anyway. [0]
panos: next item, removing XSLT. There are usage numbers.
stephen: I have concerns. I kept this up to date historically for Chromium, and I don't trust the use counters based on my experience. Total usage might be higher.
dan: even if the data were accurate, not enough zeros for the usage to be low enough.
mason: is XSLT supported officially?
simon: supported
mason: maybe we could just mark it deprecated in the spec, to make the statement that we're not actively working on it.
brian: we could do that on MDN too. This would be the first time we have something baseline widely available that we've marked as removed.
dan: maybe we could offer helpful pointers to alternatives that are better, and why they're better.
panos: maybe a question for olli. But I like brian's suggestion to mark it in all the places.
dan: it won't go far unless developers know what to use instead.
brian: talk about it in those terms also. Would anyone want to come on the podcast and talk about it? I'm guessing people will have objections.
emilio: we have a history of security bugs, etc.
stephen: yeah that was a big deal
mason: yeah we get bugs about it and have to basically ignore them, which sucks
brian: people do use it and some like it
panos: put a pin in it, and talk with olli next time?
panos: next thing is file upload control rendering
[0] https://github.com/whatwg/html/issues/11146#issuecomment-275...
simpaticoder
It's kind of too bad XSLT didn't take off. It is quite complex, until you compare it to the complexity of what now solves this problem (e.g. a build step with React and webpack and javascript absolutely required on the client-side). As the OP ably demonstrates, XSLT provides a declarative, non-javascript, non-build way to solve the basic HTML component problem. Perhaps a devastating 0-day in V8 will make us really, really want an alternative to the current best practice.
shakna
Whilst I can't be certain, I've been hearing that part of Google's want to move away from XSLT is two-fold - and relates to the idea of the security problem.
Partly, there's increasing attacks against XML.
And also, libxml2 has said "no" to security embargoes altogether. [0]
They might well consider there to be 0-days waiting in XSLT.
notpushkin
Yeah, I think that was what prompted this submission.
All this has also reignited my idea for a compile-to-XSLT templating language, too – maybe I’ll get to it finally this time; definitely if XSLT 3.0 gets into web standards: https://github.com/whatwg/html/issues/11578, https://news.ycombinator.com/item?id=44987552
Also, I’ve put together a simple XSLT playgroung a while ago! https://xsltbin.ale.sh/
SnuffBox
I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye.
johncolanduoni
To be fair, some things should be legitimately considered to be removed from the standard. O.G. XHTML basically mandated that you accept XML logic bombs and we got over that.
Also, while this is certainly Google throwing their weight around, I don’t think they are doing it for monetary advantage. I’m not sure how removing XSLT burnishes their ad empire the way things like nerfing ManifestV3 have. I think their stated reasons - that libxslt is a security disaster zone for an obscure 90s-era feature - is earnest even if its not actually in the broader web’s best interests. Now that Safari is publicly on board to go second, I suspect it’s an inevitability.
esrauch
It doesn't seem weird at all to me: standard is essentially the consensus of the major browser vendors; a spec which all of Chrome, Safari and Edge don't implement is really just a hypothetical.
The origin story of whatwg is that Apple, Mozilla and Opera decided that W3C wasn't making specs that they wanted to implement, so they created a new working group to make them.
notpushkin
If I understand correctly, Mozilla and Apple don’t really want to support it either. And the reason for that is, the spec is still at XSLT 1.0, which is super old, and current implementations are effectively abandonware. Catch-22?
johncolanduoni
I believe the spec is at XSLT 3.0 but no browser actually implemented past XSLT 1.0 (not 100% sure - almost nobody cared about this feature last month so hard to find good docs on support). HTML5 and C++ are cut from the same cloth - massive and no reference implementation so full of features that have been “standard” for 10 years but never implemented by anyone.
ekianjo
The spec is at XLST 3 right now.
chrismorgan
> nobody bats an eye
I’ve seen a lot of eye-batting about this. Although Google, Mozilla and Apple are all in favour of removing it, there’s been a lot of backlash from developers.
ekianjo
Even "champion of the web" Mozilla is on board. Tells you exactly what you need to know.
kome
so it's time to use XSLT more
raggi
I used to do this in the 2000's era, there was a lot to love about it. At the time though the IE engines were far more complete and less buggy than others with various XML features.
basscomm
Looks promising!
This looks like as good a place as any to show the XML/XSLT code that I've been tinkering with for the last couple of years: https://github.com/zmodemorg/wyrm.org
b_e_n_t_o_n
This works client side right? So when a user navigates to this page, it recursively fetches content from the server? And if you have nested includes it would waterfall?
Even single page app frameworks have mostly solved this by doing the rendering on the server instead of making multiple round trips from the client. This feels like the no-JavaScript version of Spinnergeddon.
Does the browser wait for all the includes to resolve before showing the page or does it flicker in?
dweinus
If you want server-side compilation, you could just run the xslt transform in ci/cd. It would still be a simpler solution than Jekyll in some regards, but I probably wouldn't do it for more than hobby projects
bawolff
Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else. So its not that different in terms of requests than how css would work.
OCTAGRAM
The most advanced usage of XSLT I've seen was in YBlog2, YML and YSLT, an alternative syntax for XML and XSLT. And IIUC they did not rely on browser-side although that may be still possible.
null
null
RebeccaTheDev
Three jobs ago I worked for a company that did e-learning systems for industrial clients. This was roughly 2004. One of the company owner's many ideas was a technical documentation system based on XML and XSLT. The "idea" being that technical writers or SMEs would rather write XML than, you know, use a word processor.
Unsurprisingly the idea did not take off, but I did find the XML/XSLT combination to be very interesting.
null
prettyman
[dead]
(spoiler: its XSLT)
I've been working on a little demo for how to avoid copy-pasting header/footer boilerplate on a simple static webpage. My goal is to approximate the experience of Jekyll/Hugo but eliminate the need for a build step before publishing. This demo shows how to get basic templating features with XSL so you could write a blog post which looks like
Some properties which set this approach apart from other methods: There's been some talk about removing XSLT support from the HTML spec [0], so I figured I would show this proof of concept while it still works.[0]: https://news.ycombinator.com/item?id=44952185
See also: grug-brain XSLT https://news.ycombinator.com/item?id=44393817