Why can't HTML alone do includes? • Hacker News Board

Re: Why can't HTML alone do includes?

#321

Post by j45 » Sun, May 04, 2025, 3:27 PM UTC

masklinn wrote: post #238

gpvos wrote: post #236

Earlier quoted context omitted.

Sound like it's good enough for headers and footers, which is 80% of what people need.

That’s what lots of sites used to do in the late 90s and early aughts in order to have fixed elements. It was really shit. Browser navigation cues disappear, minor errors will fuck up the entire thing by navigating fixed element frames instead of contents, design flexibility disappears (even as consistent styling requires more efforts), frames don’t content-size so will clip and show scroll bars all over, debugging i…

It’s not ideal, but t it does exist in pure html… and the OP didn’t seem to note it.

A bit of vanilla JavaScript with WebComponents is a few lines:

https://gomakethings.com/html-includes-with-web-components/

Edit: “t” was supposed to be the object tag.

Re: Why can't HTML alone do includes?

#322

Post by youngtaff » Sun, May 04, 2025, 3:27 PM UTC

john_the_writer wrote: post #270

youngtaff wrote: post #258

Earlier quoted context omitted.

I’m willing to bet the runtime overhead of assembly on the client is going to be larger than the download cost of the fragments being included server or edge side and cached

If you measure download cost in time then sure.. If you measure download cost in terms of bytes downloaded, or server costs, then nope. The cost would be smaller to cache.

Not necessarily, compression is really effective at reducing downloaded bytes

In server terms the overhead of tracking one download is going to be less that the overhead of tracking the download of the multiple components

And for client side caching to be any use then a visitor would need to view more than one page and the harsh reality is many sessions are only one page long e.g. news sites, blogs etc

Re: Why can't HTML alone do includes?

#323

Post by masklinn » Sun, May 04, 2025, 3:34 PM UTC

j45 wrote: post #321

masklinn wrote: post #238

Earlier quoted context omitted.

That’s what lots of sites used to do in the late 90s and early aughts in order to have fixed elements. It was really shit. Browser navigation cues disappear, minor errors will fuck up the entire thing by navigating fixed element frames instead of contents, design flexibility disappears (even as consistent styling requires more efforts), frames don’t content-size so will clip and show scroll bars all over, debugging i…

It’s not ideal, but t it does exist in pure html… and the OP didn’t seem to note it. A bit of vanilla JavaScript with WebComponents is a few lines: https://gomakethings.com/html-includes-with-web-components/ Edit: “t” was supposed to be the object tag.

> it does exist in pure html [...] JavaScript with WebComponents

You seem to have a rather original definition of "pure HTML".

Re: Why can't HTML alone do includes?

#324

Post by NorwegianDude » Sun, May 04, 2025, 3:48 PM UTC

lelanthran wrote: post #314

rchaud wrote: post #34

"Includes" functionality is considered to be server-side, i.e. handled outside of the web browser. HTML is client-side, and really just a markup syntax, not a programming language. As the article says, the problem is a solved one. The "includes" issue is how every web design student learns about PHP. In most CMSes, "includes" become "template partials" and are one of the first things explained in the documentation. T…

> As the article says, the problem is a solved one. It's "solved" only in the sense that you need to use a programming language on the server to "solve" it. If all you are doing is static pages, it's most definitely not solved.

Then you just pre-build the page before publishing it. It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

Re: Why can't HTML alone do includes?

#325

Post by davidfstr » Sun, May 04, 2025, 4:02 PM UTC

For HTML-in-HTML natively I use iframes and still remember how to use Frames & framesets.

Re: Why can't HTML alone do includes?

#326

Post by mikeg8 » Sun, May 04, 2025, 4:09 PM UTC

NorwegianDude wrote: post #324

lelanthran wrote: post #314

Earlier quoted context omitted.

> As the article says, the problem is a solved one. It's "solved" only in the sense that you need to use a programming language on the server to "solve" it. If all you are doing is static pages, it's most definitely not solved.

Then you just pre-build the page before publishing it. It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

An additional requests for html isn’t slow, and now I have to have a whole “build” process for something that is basically static. Not ideal

Re: Why can't HTML alone do includes?

#327

Post by masswerk » Sun, May 04, 2025, 4:12 PM UTC

charrondev wrote: post #285

masswerk wrote: post #276

Fun fact: this does work with iframes: about contact The important part is that the target iframe must have a `name` attribute (not identified by `id`.) I guess, this is a legacy of framesets & frames. (Of course, this has all the issues of framesets, as in deep linking, accessibility, etc.)

The worst part of frames is scrolling. You have to give an iframe a specific height in pixels. There is no “make this iframe the height its content wants to be (like normal HTML). This leads to two options: - your page has nested vertical scroll bars (awful UX) - you have to write JavaScript inside and outside the frame to constantly measure and communicate how tall the frame wants to be. Or you could just not use fr…

I guess, the best you could do is emulating a frameset layout with a fixed navigation and a display frame for the actual content. (By setting the overflow to `hidden` you can get rid of the outer scrollbars.)

Re: Why can't HTML alone do includes?

#328

Post by paulddraper » Sun, May 04, 2025, 4:13 PM UTC

ummonk wrote: post #228

paulddraper wrote: post #186

Earlier quoted context omitted.

Images are content. Videos are content. Objects/iframes are content. The only one that is presentational is stylesheets.

Images and videos are not semantic content. The alt attributes that describe them on the other hand are indeed semantic content.

Can you describe what semantic, non-textual content would be?

Re: Why can't HTML alone do includes?

#329

Post by moffkalast » Sun, May 04, 2025, 4:20 PM UTC

tln wrote: post #7

There used to be a thing for this https://caniuse.com/imports

Chad QQ and UC browsers, the only ones still supporting HTML imports lmao. I've never heard of them before but I like the cut of their jib.

Re: Why can't HTML alone do includes?

#330

Post by danlitt » Sun, May 04, 2025, 4:22 PM UTC

iainmerrick wrote: post #260

JadeNB wrote: post #119

Earlier quoted context omitted.

> The optimal solution would be using a template engine to generate static documents. This helps the creator, but not the consumer, right? That is, if I visit 100 of your static documents created with a template engine, then I'll still be downloading some identical content 100 times.

I'll still be downloading some identical content 100 times. That doesn't seem like a significant problem at all, on the consumer side. What is this identical content across 100 different pages? Page header, footer, sidebar? The text content of those should be small relative to the unique page content, so who cares? Usually most of the weight is images, scripts and CSS, and those don't need to be duplicated. If the co…

I care! It is unnecessary complexity, and frankly ugly. If you can avoid repetition, then you should, even if the reason is not obvious.

To give you a concrete example, consider caching (or, equivalently, compiling) web pages. Maybe you have 100 articles, which share a common header and footer. If you make a change to the header, then all 100 articles have to be uncached/rebuilt. Why? Because somebody did not remove the duplication when they had the chance :-)