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

Re: Why can't HTML alone do includes?

#51

Post by cantSpellSober » Sat, May 03, 2025, 3:26 PM UTC

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…

Well said this is many students' intro to PHP. Why not `` though?

Some content is already loaded asynchronously such as images, content below the fold etc.

> HTML is really just a markup syntax, not a programming language

flamebait detected :) It's a declarative language, interpreted by each browser engine separately.

Re: Why can't HTML alone do includes?

#52

Post by esprehn » Sat, May 03, 2025, 3:30 PM UTC

We discussed this back when creating web components, but the focus quickly became about SPA applications instead of MPAs and the demand for features like this was low in that space.

I wish I would have advocated more for it though. I think it would be pretty easy to add using a new attribute on since the parser already pauses there, so making something like would likely not be too difficult.

Re: Why can't HTML alone do includes?

#53

Post by prkl » Sat, May 03, 2025, 3:30 PM UTC

honestly, html can include css and javascript via link and style tags. there's no reason for it to not have an tag, and let the browser parsing it fetch the content to replace it.

Re: Why can't HTML alone do includes?

#54

Post by gyesxnuibh » Sat, May 03, 2025, 3:30 PM UTC

cantSpellSober wrote: post #51

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…

Well said this is many students' intro to PHP. Why not ` ` though? Some content is already loaded asynchronously such as images, content below the fold etc. > HTML is really just a markup syntax, not a programming language flamebait detected :) It's a declarative language, interpreted by each browser engine separately.

What's the ML in HTML stand for? I think that's probably the crux of the argument. Are we gonna evolve it past its name?

Re: Why can't HTML alone do includes?

#55

Post by cantSpellSober » Sat, May 03, 2025, 3:33 PM UTC

gyesxnuibh wrote: post #54

cantSpellSober wrote: post #51

Earlier quoted context omitted.

Well said this is many students' intro to PHP. Why not ` ` though? Some content is already loaded asynchronously such as images, content below the fold etc. > HTML is really just a markup syntax, not a programming language flamebait detected :) It's a declarative language, interpreted by each browser engine separately.

What's the ML in HTML stand for? I think that's probably the crux of the argument. Are we gonna evolve it past its name?

That's why I joked about flamebait, it's hypertext though, aren't anchors essentially a goToURL() click handler in some ways? Template partials seem like a basic part of this system.

> considered to be server-side

Good point! Wouldn't fetching a template partial happen the same way (like fetching an image?)

Re: Why can't HTML alone do includes?

#56

Post by jadamson » Sat, May 03, 2025, 3:34 PM UTC

bambax wrote: post #33

> We’ve got , which technically is a pure HTML solution, but they are bad for overall performance, accessibility, and generally extremely awkward here What does this mean? This is a pure HTML solution, not just "technically" but in reality. (And before iframe there were frames and frameset). Just because the author doesn't like them don't make them non-existent.

What do you mean what does it mean?

An iframe is a window into another webpage, and is bounded as such both visually and in terms of DOM interfaces. A simple example would be that an iframe header can't have drop-down menus that overlap content from the page hosting it.

They are categorically not the same DX/UX as SSI et al. and it's absolutely bizarre to me that there's so many comments making this complaint.

Re: Why can't HTML alone do includes?

#57

Post by silvestrov » Sat, May 03, 2025, 3:35 PM UTC

bambax wrote: post #33

> We’ve got , which technically is a pure HTML solution, but they are bad for overall performance, accessibility, and generally extremely awkward here What does this mean? This is a pure HTML solution, not just "technically" but in reality. (And before iframe there were frames and frameset). Just because the author doesn't like them don't make them non-existent.

The real problem with iframes is that their size is set by the parent document only.

They would be a lot more useful if we could write e.g. so the height of the iframe element is set by the abc.html document instead of the parent document.

Re: Why can't HTML alone do includes?

#58

Post by hyperhello » Sat, May 03, 2025, 3:36 PM UTC

I think it’s because it would be so easy to make a recursive page that includes itself forever. So you have to have rules when it’s okay, and that’s more complex and opaque than just programming it yourself.

Re: Why can't HTML alone do includes?

#59

Post by _heimdall » Sat, May 03, 2025, 3:41 PM UTC

If I really need HTML includes for some reason, I'd reach for XSLT. I know its old, and barely maintained at best, but that was the layer intentionally added to add programming language features to the markup language that is HTML.

Re: Why can't HTML alone do includes?

#60

Post by ludwik » Sat, May 03, 2025, 3:51 PM UTC

We used to have this in the form of a pair of HTML tags: and (not to be confused with the totally separate !). provided the scaffolding with slots for multiple frames, letting you easily create a page made up entirely of subpages. It was once popular and, in many ways, worked quite neatly. It let you define static elements once entirely client-side (and without JS!), and reload only the necessary parts of the page - long before AJAX was a thing. You could even update multiple frames at once when needed.

From what I remember, the main problem was that it broke URLs: you could only link to the initial state of the page, and navigating around the site wouldn't update the address bar - so deep linking wasn’t possible (early JavaScript SPA frameworks had the same issue, BTW). Another related problem was that each subframe had to be a full HTML document, so they did have their own individual URLs. These would get indexed by search engines, and users could end up on isolated subframe documents without the surrounding context the site creator intended - like just the footer, or the article content without any navigation.