Have you ever heard of Server Side Includes? https://en.wikipedia.org/wiki/Server_Side_Includes
[deleted]
Why can't HTML alone do includes?
11–20 of 367 posts
Re: Why can't HTML alone do includes?
#12FTA > We’ve got , which technically is a pure HTML solution, but And then on the following paragraph.. > But none of the solutions is HTML > None of these are a straightforward HTML tag Not sure what the point is. Maybe just complaining
Iframe is stuck in a rectangular box. It's not really suitable for things like site wide headers, footers and menus.
While I get your point, headers and footers and menus tend to all live within rectangular boxes.
Re: Why can't HTML alone do includes?
#13If you want to include HTML sandboxes, we have iframes. If you want it served from the server, it's just text. Putting text A inside text B is a solved problem.
The article references both of these methods with explanations of why they don't feel they answer the question posed.
Re: Why can't HTML alone do includes?
#14Iframes, while not perfect, are pretty close though...
Interaction between elements in different iframes is very restricted.
Re: Why can't HTML alone do includes?
#15If you want to include HTML sandboxes, we have iframes. If you want it served from the server, it's just text. Putting text A inside text B is a solved problem.
> Putting text A inside text B is a solved problem.
Yes, but in regards to HTML it hasn't been solved in a standard way, it's been solved in hundreds, if not thousands of non standard ways. The point of the article is that having one standard way wlcould reduce a lot of complexity from the ecosystem, as ES6 imports did.
Re: Why can't HTML alone do includes?
#16My guess: no-one needs it.
Originally, iframe were the solution, like the posts mentions. By the time iframes became unfashionable, nobody was writing HTML with their bare hands anymore. Since then, people use a myriad of other tools and, as also mentioned, they all have a way to fix this.
So the only group who would benefit from a better iframe is the group of people who don't use any tools and write their HTML with their bare hands in 2025. That is an astonishing small group. Even if you use a script to convert markdown files to blog posts, you already fall outside of it.
No-one needs it, so the iframe does not get reinvented.
Re: Why can't HTML alone do includes?
#17This was the rabbit hole that I started down in the late 90s and still haven’t come out of. I was the webmaster of the Analog Science Fiction website and I was building tons of static pages, each with the same header and side bar. It drove me nuts. So I did some research and found out about Apache server side includes. Woo hoo! Keeping it DRY (before I knew DRY was a thing).
Yeah, we’ve been solving this over and over in different ways. For those saying that iframes are good enough, they’re not. Iframes don’t expand to fit content. And server side solutions require a server. Why not have a simple client side method for this? I think it’s a valid question. Now that we’re fixing a lot of the irritation in web development, it seems worth considering.
Re: Why can't HTML alone do includes?
#18Earlier quoted context omitted.
Iframe is stuck in a rectangular box. It's not really suitable for things like site wide headers, footers and menus.
While I get your point, headers and footers and menus tend to all live within rectangular boxes.
Headers and their menus are often problematic for this approach, unless they are 100% static (e.g. HN would work but Reddit and Google wouldn't since they both put things in their header which can expand over the content). I.e. you can make it transparent but that doesn't solve eating the interactions. The code needed to work around that is more than just using JS to do the imports.
Re: Why can't HTML alone do includes?
#19I made this to get around pages being cached at CDN level, but still needing to get live data...
Re: Why can't HTML alone do includes?
#20There used to be a thing for this https://caniuse.com/imports
No HTML imports was an idea of using the HTML document format to encapsulate the 3 distinct data types needed for custom elements:
- JS for functionality via the custom elements API - HTML for layout via tags. - CSS for aesthetics via tags.
Not for just quickly and simply inserting the contents of header.html at a specific location in the DOM.