←back to thread

Show HN: JavaScript-free (X)HTML Includes

(github.com)
210 points Evidlo | 2 comments | 22 Aug 25 18:47 UTC | HN request time: 0s | 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
shakna ◴[22 Aug 25 23:38 UTC] No.44991280[source]▶
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].

[0] https://github.com/WHATWG/html/issues/11523

replies(5): >>44991471 #>>44991489 #>>44991500 #>>44991526 #>>44992056 #
SnuffBox ◴[23 Aug 25 00:00 UTC] No.44991500[source]▶
I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye.
replies(6): >>44991546 #>>44992072 #>>44992210 #>>44992387 #>>44992424 #>>44994991 #
johncolanduoni ◴[23 Aug 25 02:17 UTC] No.44992424[source]▶
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.

replies(1): >>44993872 #
Mikhail_Edoshin ◴[23 Aug 25 06:53 UTC] No.44993872{3}[source]▶
XML "logic bombs" happens when the parser expand entities eagerly. If a parser does that one can easily assemble an enormous entity that will eat up all the memory. But a more sophisticated parser won't expand entities right away and thus can merely reject oversized ones. It is really a minor issue.
replies(1): >>44999283 #
1. johncolanduoni ◴[23 Aug 25 21:28 UTC] No.44999283{4}[source]▶
There were other esoteric XML logic bomb inducing features is my recollection from all the stuff you used to have to change on the default XML Java parsers, but this was like 20 years ago so I may be misremembering.
replies(1): >>45002173 #
2. Mikhail_Edoshin ◴[24 Aug 25 07:39 UTC] No.45002173[source]▶
I myself only remember the possible misuse of disk/URL reading features. These were indeed features and were added by design, but, of course, enabling them in non-trusted input could lead to all sorts of disasters.