My HTML Wishlist: Partial HTML Includes
- Published on:
- Categories:
- Fragment Includes, Wishlist 2, HTML 2
- Current music:
- Dirty Three —
Hope (Live Radio)
- Current drink:
- Peppermint Tea
Fragment Includes
Over the last few years, some progress is happening in the land of HTML includes.
Two weeks ago, I remotely participated in a TPAC’s “It’s time for client side includes” breakout session.
There, Noam Rosenthal presented the latest proposal & prototype that follows the work on declarative partial updates — Fragment Includes.
This is very cool, and a great step towards not requiring build tools for simple HTML websites, among other things.
Even outside this discussion, the need for something like that is obvious: there is now even a W3C “No Build Community Group” organized by Ollie Williams, and during the same TPAC the group had a meeting where this need was mentioned.
I won’t go in detail about what the Fragment Includes are — I invite you to read the explainer, but, in short, in introduces a way to include files that are served with a text/fragment MIME type with a canonical .fragment extension, and stream their content right into HTML like this (syntax might change in the future):
<div id="profile"><?start name="profile">Loading...<?end></div>
<template for="profile" src="user-profile.fragment"></template>However! While I would love to see Fragment Includes in all browsers yesterday, I still think we need more. You know, I always want more, haha.
Naively, I Want More
What do I want? Or — why I think Fragment Includes are not enough?
The main limitation is that this requires its own MIME type. You can’t just take some HTML file and — whoop — insert its content into another HTML file.
And that is what I really want.
Imagine if instead of including a user-profile.fragment, which is just a headless snippet of HTML that you can’t open on its own, you could do
<div id="profile"><?start name="profile">Loading...<?end></div>
<template for="profile" src="user-profile.html#content"></template>Note the user-profile.fragment → user-profile.html#content.
Of course, the file in question needs to opt-in into being includable, and for that something like a new <meta> tag that would advertise a list of ids that can be included would be enough (or maybe some other mechanism, like, extension to a <!doctype>? Oh, heresy!).
Then, when the browser will need to include this content, it will know that it needs to start parsing the user-profile.html, check for the <meta> that allows content, and once encountering the element with the id="content", take its contents and include (only inner contents).
Any HTML page could then be its own stand-alone page with all the content, navigation, and extras, but any external page could take important snippets of it and put them inside them.
Other Includes
When I look around, I see this pattern in many other places.
SVG has fragment includes, with <view>, or with other ways. Vadim Makeev wrote a nice article about SVG Sprites in 2022.
Obsidian has .md includes!
You can do [[Some Document#fragment]] or  — use the image syntax — and it will include the corresponding section right in place!
I think I remember some other similar cases where you could include things in this way, but they escape me for now.
Why We Can’t Have This?
Why can’t we have this? Alongside the Fragment Includes?
I think most arguments that I saw:
-
HTML parser, and the fear of buffering too much.
-
Not being able to understand that document explicitly opts-in, all the CORS stuff, etc.
-
Performance issues, like the fear of including too much, downloading the content of 404 pages etc.
TBH, from my point of view, megabytes of JS bundles that we get today are much worse in every regard.
And nothing is impossible — HTML parser could have a mode that only turns on when the content is accessed through the include, it could be limited to same-origin, and if everyone would already use includes inside the included files, we could skip any of them outside our fragment, as we know that we don’t include anything from there.
When I am thinking about possibilities — and workarounds that people will do like still having the content in .fragment only, and then including it both on the inner page and outer, leading to an extra request where it is not necessary — I really want us to solve this.
Maybe not today, or in this decade, but eventually?
Again — I am really happy there is progress at least on something, but I always want more.
Like, you can dream, right? It is nice to have things in your wishlists that are achievable — and are on the horizon, like my last week’s post about SVG Linked Parameters, but I think it is important to re-iterate your wishes for the things you know were already discarded.
There were many things that were considered impossible in the past, and we have them in our browsers today. Maybe one day, someone will go and come up with a way to achieve this in an elegant and tolerable way, and we could include HTML inside our HTML happily ever after.