←back to thread

Show HN: JavaScript-free (X)HTML Includes

(github.com)
210 points Evidlo | 3 comments | 22 Aug 25 18:47 UTC | HN request time: 0.5s | source

(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

  <?xml version="1.0"?>
  <?xml-stylesheet type="text/xsl" href="/template.xsl"?>
  <page>
      <title>My Article</title>
      <content>
          some content
          <ul>
              <li>hello</li>
              <li>hello</li>
          </ul>
      </content>
  </page>
Some properties which set this approach apart from other methods:

  - no build step (no need to setup Jekyll on the client or configure Github/Gitlab actions)
  - works on any webserver (e.g. as opposed to server-side includes, actions)
  - normal looking URLs (e.g. `example.com/foobar` as opposed to `example.com/#page=foobar`)
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

Show context
xnx ◴[23 Aug 25 00:21 UTC] No.44991654[source]▶
Why didn't HTML imports stick around? https://web.dev/articles/imports
replies(1): >>44992165 #
lloydatkinson ◴[23 Aug 25 01:38 UTC] No.44992165[source]▶
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.
replies(3): >>44992418 #>>44992725 #>>44993490 #
bapak ◴[23 Aug 25 03:04 UTC] No.44992725[source]▶
Found this, it should answer your complaints:

> HTML Imports were redundant, since you need JavaScript to bring them alive anyways

replies(1): >>44993016 #
1. thayne ◴[23 Aug 25 03:59 UTC] No.44993016[source]▶
Exactly. I think the problem wasn't that browsers (specifically Firefox and Safari) were opposed to the idea of html includes in general, but they didn't like the specific proposal, in large part because it still required javascript, and added a lot of complexity for little to no benefit.

I think rejecting that proposal was the right thing to do. What disappoints me is that there hasn't been a more declaritive, simpler proposal that has gotten anywhere.

replies(2): >>44993165 #>>44993500 #
2. xnx ◴[23 Aug 25 04:29 UTC] No.44993165[source]▶
> What disappoints me is that there hasn't been a more declaritive, simpler proposal that has gotten anywhere.

Possible names: Client Side Includes (CSI): Like Server Side Includes (SSI) in Apache IHTML (inline html): Like the iframe tag, but for html instead of whole page.

3. spankalee ◴[23 Aug 25 05:38 UTC] No.44993500[source]▶
HTML Imports and HTML includes are two different ideas. HTML Imports was never like what people want from HTML includes.

HTML Imports were shelved because they didn't integrate with the JS module graph. HTML Modules will do that someday.