Show HN: JavaScript-free (X)HTML Includes

(github.com)

126 points by Evidlo 13 hours ago

65 comments

View on Hacker News

(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

tannhaeuser 35 minutes ago

This is how the simplest variant of SGML (or XML) entities have worked since 1986:

    <!doctype html [
      <!entity e system "e.html">
    ]>
    <html>
      <title>Hello, world!</title>
      <p>The content of e is: &e;</p>
    </html>
HTML was envisioned as an SGML vocabulary from day one. That SGML's document composition and other facilities were used only at authoring time and not directly supported by browsers was merely due to the very early stage of the first browser software ([1]) which directly mentions SGML even, just as HTML specs have presented HTML as a language for authoring and not just delivery since at least version 4.

There really never had been a need or call for browser devs to come up with idiosyncratic and overcomplicated solutions relying on JavaScript for such a simple and uncontroversial facility as a text macro which was part of every document/markup language in existance since the 1960s.

[1]: https://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html

Reply View 0 replies
bawolff 6 hours ago

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.

Reply View 7 replies
  • egeozcan 2 hours ago

    This is really, definitely cool, but it's important to remember that content added via CSS is purely decorative. It can't be interacted with, which is a major issue for assistive technologies like screen readers.

    Reply View 0 replies
  • Evidlo 2 hours ago

    Thanks for the CSS example.

    By the way, the advanced/ folder has a slightly more complicated example that demonstrates template inheritance and "slots".

    Reply View 1 reply
    • bawolff 17 minutes ago

      Yeah, i saw. Unfortunately the advanced example wouldn't be doable in CSS. I suppose i'm being a bit intellectually dishonest to not explicitly point that out.

      Reply View 0 replies
  • 8organicbits 5 hours ago

    > there is a lot that xslt can do that css cannot

    This latter part is why I've reached for XSLT in the past. Most recently was to convert an RSS feed into a styled page with instructions at the top. Templates and xpath can really transform a document.

    Reply View 0 replies
  • lenkite an hour ago

    Umm..your CSS example doesn't show any template includes. No way to put header/footer in separate files.

    Reply View 1 reply
    • bawolff 27 minutes ago

      The original example didn't have that either.

      Reply View 0 replies
  • Pxtl 2 hours ago

    > i'd point out you can do the same thing with CSS

    Cool when are they removing CSS from the standard?

    Reply View 0 replies
ulrischa an hour ago

To overcome the two problems here (client side loading the template and ending browser support) you could throw in php in the mix and have a wonderful solution for templating with bullet proof standards: // XML $xml_doc = new DOMDocument(); $xml_doc->load("file1.xml");

// XSL $xsl_doc = new DOMDocument(); $xsl_doc->load("file.xsl");

// Proc $proc = new XSLTProcessor(); $proc->importStylesheet($xsl_doc); $newdom = $proc->transformToDoc($xml_doc);

// Output print $newdom->saveXML();

XSLT lacks functionality? No problem, use php functions in xslt: https://www.php.net/manual/en/class.xsltprocessor.php

Reply View 0 replies
xnx 7 hours ago

Why didn't HTML imports stick around? https://web.dev/articles/imports

Reply View 7 replies
  • lloydatkinson 6 hours ago

    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.

    Reply View 6 replies
    • spankalee 2 hours ago

      I'm sorry, this a dumb comment that has no basis in reality.

      HTML Imports was part of the initial set of the web components specs, there's no "cabal" or whatever that got its hands on it, and it didn't rely on JavaScript, not in the way you're probably referring to.

      It was only opposed because it was separate from the JS module system, not because it relied on JS.

      It's replacement: The HTML Modules proposal has general support from all vendors, just no one has put together a complete proposal yet.

      Reply View 0 replies
    • bapak 5 hours ago

      Found this, it should answer your complaints:

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

      Reply View 3 replies
      • thayne 4 hours ago

        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.

        Reply View 2 replies
shakna 8 hours ago

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

Reply View 29 replies
  • chrismorgan 6 hours ago

    > 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.

    Reply View 5 replies
    • shakna 5 hours ago

      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...

      Reply View 4 replies
      • magicalist 5 hours ago

        > But they did anyway.

        Did what? The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome, but you forgot to add that. As best as I can tell, the GP is right and you're confused.

        Reply View 0 replies
      • chrismorgan 4 hours ago

        By “started talking about it this month” I meant this specific advocation for removing it. Yes, it’s been talked about for years, but this time it’s specific.

        Reply View 2 replies
  • simpaticoder 8 hours ago

    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.

    Reply View 5 replies
    • shakna 6 hours ago

      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.

      [0] https://news.ycombinator.com/item?id=44381093

      Reply View 0 replies
    • MrJohz 3 hours ago

      I think the big difference there is that browsers are only responsible for Javascript, which is a big general purpose solution that solves a lot of problems and not just templating/styling XML. Everything else either happens server-side (build steps and webpack) or is userland code that lives inside the sandbox. So there's one task for browsers to do (make a fast and secure Javascript sandbox), and if that works that developers can do whatever they want. Whereas XSLT is not a general purpose tool in the same way, and so needs to be maintained in addition to Javascript and anything else that exists.

      If course XSLT can also be used server-side (which is probably a good idea if you want access to the latest features and not some ancient, frozen version of the spec), but browsers aren't the reason that that didn't take off. My guess there is that it's just not an intuitive way of manipulating and templating data in comparison to more traditional HTML templating libraries.

      Reply View 0 replies
    • AgentME 4 hours ago

      React supports rendering to HTML ahead of time (SSR) which doesn't need any client-side javascript, and this is a prominent feature of most frameworks using React. This feature of React was one of its major innovations over many other front-end frameworks of the time.

      Reply View 1 reply
      • degamad 2 hours ago

        > React supports rendering to HTML ahead of time (SSR)...

        So does XSLT?

        Reply View 0 replies
    • bawolff 3 hours ago

      I don't think react is comparable.

      React's main thinh is client side reactivity, something that xslt doesn't offer.

      A closer comparison would be a templating engine that does statuc conversion to html.

      Reply View 0 replies
  • notpushkin 8 hours ago

    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/

    Reply View 1 reply
  • SnuffBox 8 hours ago

    I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye.

    Reply View 13 replies
    • esrauch 6 hours ago

      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.

      Reply View 0 replies
    • notpushkin 8 hours ago

      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?

      Reply View 6 replies
      • johncolanduoni 5 hours ago

        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.

        Reply View 2 replies
      • ekianjo 5 hours ago

        The spec is at XLST 3 right now.

        Reply View 2 replies
    • johncolanduoni 5 hours ago

      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.

      Reply View 1 reply
      • Mikhail_Edoshin an hour ago

        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.

        Reply View 0 replies
    • chrismorgan 6 hours ago

      > 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.

      Reply View 1 reply
      • johncolanduoni 4 hours ago

        Most of whom had never heard of XSLT before today - some were likely born after it had faded into obscurity. I don’t blame people for hating Google for whatever reason, but this is a weird way to try to stick it to them.

        Reply View 0 replies
    • ekianjo 5 hours ago

      Even "champion of the web" Mozilla is on board. Tells you exactly what you need to know.

      Reply View 0 replies
  • kome 8 hours ago

    so it's time to use XSLT more

    Reply View 0 replies
raggi 8 hours ago

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.

Reply View 0 replies
b_e_n_t_o_n 8 hours ago

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?

Reply View 7 replies
  • dweinus 6 hours ago

    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

    Reply View 0 replies
  • bawolff 7 hours ago

    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.

    Reply View 5 replies
    • magicalist 5 hours ago

      > Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else

      At least the browser has to load template.xsl before it can know it has to load the css file though, right? And this is just a simple demo page.

      Reply View 4 replies
      • bawolff 19 minutes ago

        I guess its ine extra layer, but its not like we've gone 14 layers deep or something.

        I imagine preloading the css file using the http link header would solve this problem.

        Reply View 0 replies
      • b_e_n_t_o_n 3 hours ago

        It's making three round trips. The first is to get the original xml file, then it's to load the second xml file, then it's to load the stylesheet.

        Now you can imagine with a real site, you will have many includes per page, each one perhaps using includes of it's own. You end up with a really bad waterfall where it can take a long time for a page to load because it's going back to the server constantly, whereas if you did it on the server it would be a single round trip.

        Early SPA's did this, they would load a shell and then begin fetching from the client. Some still do but we know better than to do this for things that aren't web apps.

        Reply View 2 replies
[removed] 8 hours ago
[deleted]
Reply View 0 replies
OCTAGRAM 6 hours ago

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.

Reply View 0 replies
RebeccaTheDev 7 hours ago

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.

Reply View 0 replies
[removed] 8 hours ago
[deleted]
Reply View 0 replies
[removed] 8 hours ago
[deleted]
Reply View 0 replies