Hacker News Reader

Comment by vaylian | Hacker News Reader

This is such an obvious missing feature in HTML. I wonder why we don't have <include src="header.html"> yet.

You can do client-side includes with iframes (or with JavaScript, e.g. a web component like `<include-fragment>`). https://www.webcomponents.org/element/include-fragment-eleme...

But client-side includes are inherently slower on first load than server-side includes, because they require an additional round trip to fetch the partial content.

That performance hit is particularly painful for the header. You either have to show a flash of content without the header, causing the page to jump around when the header loads in, or slow down the entire page while you wait for the second round-trip request.

"But what about subsequent page loads, where the header is in the browser's cache?" That's fine, but the savings are pretty minimal. Headers and footers are typically not a lot of bytes on the wire, so there's not a huge savings.

If all you want is the developer experience of writing HTML "by hand" without copying and pasting your header, server-side includes are a battle-tested solution.

> Headers and footers are typically not a lot of bytes on the wire, so there's not a huge savings.

In that case just flip it-- give links as data urls which hard-code the header/footer and which use a client-side include for the content. :)

Old links eternally provide the navigation the users know and love!

HTML itself doesn't have it because HTML was understood to be an SGML application/vocabulary, and SGML does have mechanisms for fragment inclusion/sharing. For your requirements (pretty much the simplest case), you'd use entities:

    <!doctype html [
      <!entity hdr system "header.html">
      ...
    ]>
    &header <!-- content of header.html gets included here -->
    ... page body content goes here ...

SGML can also take care of inferring omitted <html>, <head>, and <body> tags here.

Moreover, you can also use more sophisticated entity expansion and template mechanisms with type checking, proper HTML-aware auto-escaping (for things such as potentially malicious user-provided comments), table-of-content/nav generation, etc. etc.

> This is such an obvious missing feature in HTML. I wonder why we don't have <include src="header.html"> yet.

Well, the way this would work... already exists. It would be just an iframe.

Fun fact: ViolaWWW (1992) had this! https://en.wikipedia.org/wiki/ViolaWWW#Firsts

  <INSERT SRC="a_quote.html">

You did have this in the past. HTML imports were a wonderful thing once upon a time. No need for heavy JS-based web components.

https://web.dev/articles/imports https://www.w3.org/TR/html-imports/

Thanks! Do you know why the proposal was discontinued?

Because commercial browser vendors felt that effectively permitting re-usable components without the need of Javascript could normalize the user of No-JS websites which would be bad for ad/tracking purposes. Note that web-components today mandate use of JS. You can't disable JS.

That's exactly what iframes are designed to do. Though they do have... downsides

True, though you probably only need to invert some relationships to get the same behavior. Instead of a page including the header it wants, you have it iframe the content you want. Your landing page, then, can use javascript to pull out the location to know which page to include.

Functionally, it would be about the same? Caching would even largely go the way you want it to with it hitting the main layout page first, and then pulling in the content pages.

Edit: Amusingly, this organization strategy also provides a relatively easy way to try out other layouts. Since you can make a new driver page that iframes in your content.

Sure, but the <head> doesn't go into the body DOM either? Pretty sure header.html was supposed to be the navigation/menu and similar, so that wouldn't be in the <head> either

Many pages have the same <link rel="stylesheet"> and <script> tags which affect DOM content inside the <body>.

If only there were a hypertext pre-processor...

You are missing the point. Repeated document fragments have been a pattern since the very beginning of HTML. This is a missing feature. Hypertext pre-processors are just a workaround.

> . Repeated document fragments have been a pattern since the very beginning of HTML. This is a missing feature.

With webcomponents, it's now trivial to do client-side includes. It's not really a missing feature anymore. See this post here (which, for some reason is being downvoted): https://news.ycombinator.com/item?id=40847759

I like web components. But they require JavaScript. I'm thinking about something that is pure HTML.

> But they require JavaScript.

Sure, but only for implementing your own. In practice they don't typically require the author of the page to know any Javascript. I'm using a client-side include by writing only HTML tags (with a 'remote-src' attribute).

It's no different from not having to know C++ in order to write HTML which is rendered by C++ code. The implementation just doesn't matter, because the user (in this case the page/site author) never needs to examine it.

I'm not someone deep in webtech. There isn't?

They are missing an <irony> tag

It's a PHP joke.

https://www.php.net/manual/en/preface.php

m4 is on every POSIX system.

Reply on news.ycombinator.com