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

Re: Why can't HTML alone do includes?

#261

Post by librasteve » Sun, May 04, 2025, 9:52 AM UTC

HumanOstrich wrote: post #214

matchagaucho wrote: post #165

Earlier quoted context omitted.

I've become a fan of https://htmx.org for this reason. A small 10KB lib that augments HTML with the essential good stuff (like dynamic imports of static HTML)

Seems like overkill to bring in a framework just for inlining some static html. If that's all you're doing, a self-replacing script tag is neat: function includeHTML(url) { const s = document.currentScript fetch(url).then(r => r.text()).then(h => { s.insertAdjacentHTML('beforebegin', h) s.remove() }) } ... includeHTML('/footer.html') The `script` element is replaced with the html from `/footer.html`.

this here is the main idea of HTMX - extended to work for any tag p, div, content, aside …

there are many examples of HTMX (since it is a self contained and tiny) being used alongside existing frameworks

of course for some of us, since HTMX brings dynamic UX to back end frameworks, it is a way of life https://harcstack.org (warning - raku code may hurt your eyes)

Re: Why can't HTML alone do includes?

#262

Post by librasteve » Sun, May 04, 2025, 9:53 AM UTC

chipsrafferty wrote: post #144

daveac wrote: post #143

I desperately want to back to crafting sites by hand and not reach for react/vue as a default. I do a lot of static and tempory sites that do very little

Use HTMX.

this

(and this https://harcstack.org)

Re: Why can't HTML alone do includes?

#263

Post by librasteve » Sun, May 04, 2025, 9:54 AM UTC

dietsche wrote: post #147

I think the authors of htmx have the same questions :)

this!

(and this https://harcstack.org)

Re: Why can't HTML alone do includes?

#264

Post by DemocracyFTW2 » Sun, May 04, 2025, 10:11 AM UTC

_heimdall wrote: post #200

mark_and_sweep wrote: post #166

Earlier quoted context omitted.

What bug specifically?

Couldn't find a good link earlier, guess I didn't have quite the right keywords for search. Here we go, looks like its 17 years old now: https://bugzilla.mozilla.org/show_bug.cgi?id=98168#c99

from the linked thread:

> The only combination that fails to render these entities correctly is Firefox/XSLT.

Which is one good reason not to adopt XSLT to implement HTML includes. You just don't know what snags you'll hit upon but you can be sure you'll be on your own.

> Bug 98168 (doe) Opened 24 years ago Updated 21 days ago

Well it does look like someone's still mulling over whether and how to fix it... 24 years later...

Re: Why can't HTML alone do includes?

#265

Post by wodenokoto » Sun, May 04, 2025, 10:14 AM UTC

In the nineties we fixed it with frames or CGI. I still think of it as one of those “if it was fiction it would be unrealistic” things (although, who writes fictional markup standards?)

Re: Why can't HTML alone do includes?

#266

Post by john_the_writer » Sun, May 04, 2025, 10:41 AM UTC

adregan wrote: post #94

amadeuspagel wrote: post #78

Earlier quoted context omitted.

This argument applies just as much to CSS and JS. Why do they include "includes" when you can just bundle on the server?

For caching and sharing resources across the whole site, I suppose.

But that would apply to and and too. We could cache them.

Re: Why can't HTML alone do includes?

#267

Post by rs186 » Sun, May 04, 2025, 10:42 AM UTC

rs186 wrote: post #26

I guess for the similar reason that Markdown does not have any "include" ability -- it is a feature not useful enough yet with too many issues to deal with. They are really intended to be used as "single" documents.

Yeah people downvote me but can't bother to leave a comment.

If you disagree, and you think you are in the right, you probably have a somewhat good argument you can use in a reply.

The fact that you don't means my explanation makes sense.

Re: Why can't HTML alone do includes?

#268

Post by safety1st » Sun, May 04, 2025, 10:51 AM UTC

echelon wrote: post #217

int_19h wrote: post #183

Earlier quoted context omitted.

We also had a brief detour into XML with XHTML, and XML has XInclude, although it's not a required feature.

It's too bad we didn't go down the XHTML/semantic web route twenty years ago. Strict documents, reusable types, microformats, etc. would have put search into the hands of the masses rather than kept it in Google's unique domain. The web would have been more composible and P2P. We'd have been able to slurp first class article content, comments, contact details, factual information, addresses, etc., and built a wealth…

I'm as big a critic of Google as anyone, but I'm always surprised at modern day takes around the lost semantic web technologies - they are missing facts or jumping to conclusions in hindsight.

Here's what people should know.

1) The failure of XHTML was very much a multi-vendor, industry-wide affair; the problem was that the syntax of XML was stricter than the syntax of HTML, and the web was already littered with broken HTML that the browser vendors all had to implement layers of quirk handling to parse. There was simply no clear user payoff for moving to the stricter parsing rules of XML and there was basically no vendor who wanted to do the work. To my memory Google does not really stand out here, they largely avoided working on what was frequently referred to as a science project, like all the other vendors.

2) In subsequent years, Google actually has actually delivered a semantic web of sorts: https://developers.google.com/search/docs/appearance/structu...

A few things stand out as interesting. First of all, the old semantic web never had a business case. JSON+LD Structured Data does: Google will parse your structured data and use it to inform the various snippets, factoids, previews and interactive widgets they show all over their search engine and other web properties. So as a result JSON+LD has taken off massively. Millions of websites have adopted it. The data is there in the document. It is just in a JSON+LD section. If you work in SEO you know all about this. Seems to be quite rare that anyone on Hacker News is aware of it however.

Second interesting thing, why did we end up with the semantic data being in JSON in a separate section of the file? I don't know. I think everyone just found that interleaving it within the HTML was not that useful. For the legacy reasons discussed earlier, HTML is a mess. It's difficult to parse. It's overloaded with a lot of stuff. JSON is the more modern thing. It seems reasonable to me that we ended up with this implementation. Note that Google does have some level of support for other semantic data, like RDFa which I think is directly in the HTML - it is not popular.

Which brings us to the third interesting thing, the JSON+LD schemas Google uses, are standards, or at least... standard-y. The W3C is involved. Google, Yahoo, Yandex and Microsoft have made the largest contributions to my knowledge. You can read all about it on schema.org.

TL;DR - XHTML was not a practical technology and no browser or tool vendor wanted to support it. We eventually got the semantic web anyway!

Re: Why can't HTML alone do includes?

#269

Post by john_the_writer » Sun, May 04, 2025, 10:54 AM UTC

socalgal2 wrote: post #172

There are all kind of issues with HTML include as others have pointed out If main.html includes child/include1.html and child/include1.html has a link src="include2.html" then when the user clicks the link where does it go? If it goes to "include2.html", which by the name was meant to be included , then that page is going to be missing everything else. If it goes to main.html, how does it specify this time, use inclu…

The include logic of include2.html missing everything else would also apply to all other includes.

If a user clicked a link with src="include.css" then it'll be rubbish.

It would be good for static data.. images, css, and static html content.

Re: Why can't HTML alone do includes?

#270

Post by john_the_writer » Sun, May 04, 2025, 11:11 AM UTC

youngtaff wrote: post #258

thayne wrote: post #159

Earlier quoted context omitted.

One benefit of doing it on the client is the client can cache the result of an include. So for example, instead of having to download the content of a header and footer for every page, it is just downloaded once and re-usef for future pages

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.