Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why can't HTML alone do includes?

frontendmasters.com

Post reply on HN
Print view View original

351–360 of 367 posts

Re: Why can't HTML alone do includes?

#351

Post by MrBuddyCasino »

tsimionescu wrote: post #235
echelon wrote: post #217

Earlier quoted context omitted.

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…

The semantic web is a silly dream of the 90s and 00s. It's not a realizabile technology, and Google basically showed exactly why: as soon as you have a fixed algorithm for finding pages on the web, people will start gaming that algorithm to prioritize their content over others'. And I'm not talking about malicious actors trying to publish malware, but about every single publisher that has theoney to invest in figurin…

It was certainly a good way to win EU grants.

Re: Why can't HTML alone do includes?

#352

Post by fooker »

sbarre wrote: post #179
fooker wrote: post #161

Earlier quoted context omitted.

> Why not have a simple client side method for this? Like writing a line of js?

A line of JS that has to run through the Javascript interpreter in your browser rather than a simple I/O operation? If internally this gets optimized to a simple I/O operation (which it should) then why add the JS indirection in the first place?

> simple I/O operation

That’s the reason it doesn’t get implemented. Nobody wants the simple I/O operation based inclusion. The moment you try to propose it, there’ll be demands to add conditional logic or macros. More relevant for the web is instantiating html templates, which will undoubtedly get piled onto such a feature. And pretty soon you have yet another:

> interpreter in your browser

Might as well use the one already there.

Re: Why can't HTML alone do includes?

#353

Post by rapnie »

librasteve wrote: post #261
HumanOstrich wrote: post #214

Earlier quoted context omitted.

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)

If you want it more straight-forward and simple hypermedia approach, then check out https://data-star.dev (highly recommended, there are great youtube video's where the maintainers discuss their insights). Following up where htmx took things.

Re: Why can't HTML alone do includes?

#354

Post by Kuyawa »

Kuyawa wrote: post #176

This is the closest we can do today: -- index.html Hello includes -- header.js document.currentScript.outerHTML = ` Header ` -- footer.js document.currentScript.outerHTML = ` Footer ` Scripts will replace their tags with html producing a clean source, not pretty but it works on the client

Or this:

  
    
    
      Hello includes
    
    
  
  
  (async function include(){
    const objs = document.getElementsByTagName('include')
    const tags = Array.from(objs)
    for(tag of tags){
      const src  = tag.getAttribute('src')
      const data = await fetch(src)
      const html = await data.text()
      tag.outerHTML = html
    }
  })()
* beware autoclosing tags won't work

Re: Why can't HTML alone do includes?

#355

Post by int_19h »

immibis wrote: post #275
int_19h wrote: post #250

Earlier quoted context omitted.

Me personally, I didn't even care that much about strict semantic web, but XML has the benefits of the entire ecosystem around it (like XPath and XSLT), composable extensibility in form of namespaces etc. It was very frustrating to see all that thrown out with HTML5, and the reasoning never made any sense to me (backwards compatibility with pre-XHTML pages would be best handled by defining a spec according to which t…

If XHTML was literally just HTML but with XML syntax, it would be pretty cool.

That's exactly what it was, though - HTML 4.01 Strict but with XML syntax.

Re: Why can't HTML alone do includes?

#356

Post by bazoom42 »

immibis wrote: post #350
bazoom42 wrote: post #349

Earlier quoted context omitted.

It is.

XHTML 1.0 was, and they evolved it incompatibly.

There was an ill-advised XHtml 2.0 project which was supposed to be incompatible, but it was abandoned. Currently xhtml is defined as an alternative “serialization” of html, but the semantics are exactly the same as html.

Re: Why can't HTML alone do includes?

#357

Post by RenThraysk »

bradly wrote: post #287
RenThraysk wrote: post #284

Earlier quoted context omitted.

Don't Service Workers API provide this now, essentially act like a in-browser proxy to the server. https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

Rational or not, some of us try very hard to avoid JavaScript based solutions.

As a dev from the early 90s, I share the sentiment. Watching javascript become more and more complex and bloated for little to no benefit to the end user.

Re: Why can't HTML alone do includes?

#358

Post by rbanffy »

bawolff wrote: post #256
rbanffy wrote: post #225

Earlier quoted context omitted.

A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes.

So would any form of html inclusion.

Unless the renderer starts after all HTML is retrieved, or the container element has a defined size.

Re: Why can't HTML alone do includes?

#359

Post by JanSchu »

Why can’t I just write and be done with it?

We almost could. Chrome shipped a draft of HTML Imports back in 2014. You’d do exactly that, the browser would fetch the fragment, parse it, and make it available for insertion. The idea died for three reasons that still apply today:

Execution‑order and performance hazards. Images, scripts, and styles are fire‑and‑forget: the preload scanner sees a URL, starts the fetch, and the parser keeps streaming. With HTML fragments you need the full subtree before you can finish parsing the parent document (otherwise IDs, custom‑element upgrades, , etc. fire in the wrong order). That either stalls the parser—horrible for TTFB—or forces async insertion, which produces layout shifts. Everyone hated both outcomes.

Security and isolation. If an imported fragment can run scripts it becomes an XSS foot‑gun; if it can’t run scripts it breaks a surprising amount of markup (think onerror, custom elements with module scripts, CSP inheritance, etc.). The platform already has an “HTML that can’t run scripts” container: it’s called an iframe. Anything more permissive lands in a swamp of half‑trusted execution.

The “circular dependency” tar‑pit. Templates inherit CSS scopes, custom element registries, and base URLs from the document that instantiates them. Once you let HTML pull in more HTML, those scopes can nest arbitrarily—and can link back to parents. The HTML spec team tried to spec out the edge‑cases and basically threw up their hands. (There’s a famous TAG thread titled “HTML Imports considered harmful” that reads like war diaries.)

Meanwhile developers solved the “shared header” problem higher up the stack—SSI, PHP include, SSG partials, React components, you name it—so browser vendors didn’t see a payoff big enough to justify the complexity. The attitude became: “composition is a build‑time concern, not a runtime primitive.”

Could it ever come back? Maybe, but the bar is higher now that everyone has a build step. A proposal would need to:

Stream (no parser‑blocking)

Sandbox (no ambient script execution)

Deduplicate (avoid circular fetch hell)

Play nicely with CSP, SRI, origin isolation, and the module graph

That starts to look a lot like… , which we already have—just not the ergonomic sugar we wish for.

So the short answer is: HTML includes are easy in user‑land but devilishly hard to make safe, fast, and spec‑compliant in the browser itself.

Re: Why can't HTML alone do includes?

#360

Post by baggy_trough »

teg4n_ wrote: post #86
baggy_trough wrote: post #81

Earlier quoted context omitted.

You can achieve that with js in the parent document.

You can achieve everything with JS in the parent document, it doesn’t mean it should be required or even recommended

We could also achieve it with single tape Turing machines, but with js in the parent document it takes just a few lines and is practical to do.
Post reply on HN