<embed-html src="header.html"> - a way to do light, easy, fast HTML embedding

[Dan Q]

Background

Remember @Tuffy!'s thread about how to serve the same header/sidebar on multiple pages?

The short of it is: some folks are using PHP. Some folks are using SSI (Nekoweb can do this!). A good number of folks are using Static Site Generators.

But most folks here are using either <iframe>s (which have some problems) or JavaScript (which has different problems).

I looked at some of the ways people were using JavaScript and thought... I can make this easier! Want to see what I came up with?

<embed-html>

Have you come across Web Components? I really love them. Basically, they're a way to use JavaScript to invent your own HTML elements!

So I've made one for exactly this purpose. If you're using (or considering using) JavaScript or <iframe>s to embed the same content across multiple pages (e.g. headers, menus, sidebars, whatever!), this is for you!

I made a one-page site to explain in detail, but the short of it is you just do this:

1. Add the JavaScript to a page (anywhere you like!):

Code

<script type="module" src="//embed-html.danq.dev/embed-html.js"></script>

(it's fine to hotlink it just like this, or you can download it and host it yourself; whatever you like!)

2. Use the new <embed-html> element to embed HTML inside other HTML:

Code

<embed-html src="sidebar.html"></embed-html>

Now the contents of sidebar.html are embedded on your page. Do that on every page and your sidebar gets shared throughout your site. Update it in one place and every page gets updated. Neat, eh?

Rather I "show, not tell"? Cool. embed-html.neocities.org is an (ugly and bland!) Neocities site I threw together that has a nav bar "shared" between all three pages. "View Source" to see how it works!

(Note that "Inspect Element" will not show you how it works, because it'll show you the result of the transformation: when you "Inspect Element" on that page, it'll look like each page manually had the nav bar added to it, "the hard way". This is one of those occasions where "View Source" and "Inspect Element" differ wildly!)

There's more it can do, too. <embed-html src="sidebar.html" cache></embed-html> will cache the sidebar in your visitors' browsers so they don't see a "flash" as it loads: it's instant! (But in exchange, when you change the file they won't see it until the second time it loads.) Got lots of embeds on a page and only want them to load when they scroll into view? <embed-html src="sidebar.html" lazy></embed-html> is your friend. Go read the guide if you're interested in the full details.

It even supports embedding CSS and JS within your embedded sub-pages (which most other JS approaches struggle with!).

Oh, and the whole thing is open source/public domain so you can take it and change it to your needs if you like and you don't even have to credit me. Just take it!

But if you find it useful at all, or even if you've just got ideas to improve it, then let me know! Melonlanders are getting to see this first.

[Tuffy!]

This is a really neat approach with some nice advantages.

I just flew over the code so please correct me if I'm wrong: It still needs a JS capable browser (which isn't that bad as most do have one). I could think of using this method and serving a rudimentary fallback nav menu for the main categories by using <noscript></noscript> tags to non js browsers.

[Dan Q]

This is a really neat approach with some nice advantages.

I just flew over the code so please correct me if I'm wrong: It still needs a JS capable browser (which isn't that bad as most do have one). I could think of using this method and serving a rudimentary fallback nav menu for the main categories by using <noscript></noscript> tags to non js browsers.

Yes, it still need JavaScript to work. But you don't need <noscript> tags: you can just put the "fallback" content (what to show to people for whom the JS doesn't work, e.g. a hyperlink to the navigation page if it's a navbar) inside the <embed-html>...</embed-html> block. Part of the joy of Web Components is that if they fail for any reason, e.g. JS is disabled, fails to load, breaks, etc., then web browsers still render the contents of the tag. So that's the fallback! E.g.:

Code

<embed-html src="/nav.html" cache>
  <!-- this bit is "like" noscript content; it'll show if the embed fails for ANY reason! -->
  <p>
    My menu should have loaded, but it didn't!<br>
    <a href="/nav.html">Find your way around my site here!</a>
  </p>
</embed-html>

This is superior to using a <noscript> tag because there exist failure conditions under which JS will be enabled, but won't work! E.g. if a script has a syntax error, crashes, is erroneously blocked by an adblocker or so on then <noscript> tags won't be rendered, even though the script itself didn't run. But embedding the content into a Web Component like this means that the user will always see something: either they'll see the fallback content, or they'll see the embedded content, no matter what the JS does or doesn't do!

So yeah: yes, this requires JS. But its fallback is better than using <noscript> because it "fails safe" under a greater diversity of circumstances.

[Tuffy!]

Thanks for explaining. Nifty piece of a script :)

[littlelum]

Hey, I just want to thank you for this.    I was procrastinating a lot of stuff on my site due to not being sure how to handle headers. (My previous method got stuck in the cache, so making changes wouldn't work!). Now I can continue on, knowing that if I change my mind in the future (I will!), making changes won't be so painful.

[Kallistero]

Hey, this is how the popular Web framework Angular works under the hood! 

When you build an Angular component, you're defining a custom HTML component that renders as other re-deployable HTML, along with behaviors in a Javascript/Typescript module. So you define my-component as "< my-component > lots of stuff < /my-component >" and the lots of stuff can include other HTML. Then, you can compose it with other components; you can make "< my-other-component > lots of other stuff < my-component > < my-component > lots more stuff < /my-other-component >" that has two instances of the first component in it. It also has directives that allow you to loop things or have them show up or disappear based on some condition, written right into the HTML 

If you view-source the HTML pages that it creates, you'll still see those custom my-component & my-other-component HTML elements on the page (unless you add an instruction that tells them not to do that). The framework is open-source, too. It's really taking the concept to a logical extreme, though, so you wind up with lots of Javascript. I always liked the idea of custom HTML tags, ever since I figured that browsers are just fine with them, it's cool to see people take it in another direction

[Dan Q]

Hey, this is how the popular Web framework Angular works under the hood! 

Indeed. Web frameworks like Angular got in early with componentisation, but nowadays they're a first-class citizen of the Web.

In the same way at XHR and DOM manipulation was really hard in the early days but then jQuery came along and made it really easy, but now both are well-standardised across all browsers so you don't need jQuery any more... it feels like the time has come for the heavyweight componentisation frameworks to sling their hooks too: they're not needed any more! (And you can do a lot more with a lot less: if you really want some of their convenience features then ultra-light frameworks like Reef and Elena can provide all the same conveniences but at about a tenth of the footprint, by leaning on the stuff the Web gives you for free).

Of course, like jQuery I expect we'll continue to see React, Vue, Angular and friends continue to be used for existing and even new projects for a long time, because people are familiar with them and don't want to have to learn a new way (even if it's more standards-compliant and faster!), or because they want to lean on everything that's come before (existing component libraries, their own architecture, etc.).

tl;dr: jQuery gave us simple XHR and DOM manipulation, then they became a standard part of the Web and jQuery became redundant (but hasn't quite gone away, somehow). React, Angular, Vue etc. gave up simple componentisation and state management, then they became a standard part of the Web and React, Angular Vue etc. became redundant (but that happened relatively recently, so I don't think they're going to disappear overnight given how long it's taking jQuery!).