I’m obsessed with this basic web need.
You’ve got three pages:
- index.html
- about.html
- contact.html
You need to put the same header on all three pages.
Our developer brains scream at us to ensure that we’re not copying the exact code three times, we’re creating the header once then “including” it on the three (or a thousand) other pages.
There are so many solutions to this problem
We don’t need to list them all here. I documented some of them one time, but there are many more.
We’ve got JavaScript to go fetch the HTML and insert it. We’ve got old school web server directives. Any static site generator can do it. Task runners can do it. Templating languages tend to have include functionality. Any backend language can generate HTML on the fly. I’ve seen several Web Components purpose-built for this. We’ve got <iframe>, which technically is a pure HTML solution, but they are bad for overall performance, accessibility, and generally extremely awkward here, but we can extract them. We can just not worry about includes at all and trust our code editors powerful find and replace tools.
But none of the solutions is HTML
None of these are a straightforward HTML tag. None of these are just some HTML way of saying “go get this HTML and put it here”, like <img> is for “go get this image and put it here.
Why?
No, really, why?
I’m sure there are reasons. Normally, web standards and browsers are all about “paving the cowpaths”, that is, providing solutions around what developers are already doing. I’d wager (counts fingers) pretty much all websites need this ability, and all of them reach for different additional non-web-standard tooling to get it done. That’s weird.
So what are those reasons?
- Does it wreck the preload scanner? As in, it could have very bad web performance issues?
- Would it have to be async and thus have issues with jerky/shifty loading experiences?
- Does it introduce some kind of complexity that harms the purity of HTML or something?
- Is it the difficulty of handling nested includes? Circular includes?
- Is it pushback from web hosting that a feature like this would increase web requests dramatically?
- Would the restrictions be too strict to make it useful? Like for whatever reason it’s cool to load images and CSS and JS from other domains, but HTML would likely be restricted.
- Is there something problematic about the idea that I haven’t listed here?
- Is there actually no real desire for this and I’m just a weirdo thinking there is?
If anyone has been a part of these discussions or knows exactly why this is, or you just have general thoughts, leave a comment!
Broadly speaking, there’s one simple reason:
HTML became rhe deathly standard, not a “living standard”.
Look at how many tags have been born since HTML5 became the final version of HTML.
Then compare that to how many tags we got before HTML5.
Rather than being some endless source of ongoing innovation that perhaps suited browser developer desires to release support for one tag this month, two tags another month … ‘rolling release’ fashion … without targeting a HTML5, we’ve ended up with a pathetic trickle of very few new tags and then the “well, do it yourself with ‘web components'”.
So now there’s all this confusion between framework components and all the guff around ‘web components’ like shadow bloody DOMs and so forth.
Meanwhile everyone’s hyper over-engineered their publishing to the point of requiring compilation. What, did we all want to feel like legitimate desktop developers?
Then everyone’s getting rather excited about an elementary ‘no spoilers’ tag combo that is details and summary.
Basically what I’m trying to say is actual HTML evolution died when theyv killed major versions and pretended to leave a ‘living standard’ in it’s place. Ignoring all the needs developers have had to implement by other means. For example, the topic of this article was addressed by jQuery about 15 years ago.