5 ms·
This is such an obvious missing feature in HTML. I wonder why we don't have <include src="header.html"> yet.
by vaylian 2y ago
This is such an obvious missing feature in HTML. I wonder why we don't have <include src="header.html"> yet.
- itomato 2y agoIf only there were a hypertext pre-processor...
- vaylian 2y agoYou 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.
- lelanthran 2y ago> . 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 https://news.ycombinator.com/item?id=40847759
- vaylian 2y agoI like web components. But they require JavaScript. I'm thinking about something that is pure HTML.
- lelanthran 2y ago> 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.
- tomrod 2y agoI'm not someone deep in webtech. There isn't?
- vaylian 2y agoThey are missing an <irony> tag
- arcanemachiner 2y agoIt's a PHP joke. https://www.php.net/manual/en/preface.php https://www.php.net/manual/en/preface.php
- kevin_thibedeau 2y agom4 is on every POSIX system.
- cobbal 2y agoThat's exactly what iframes are designed to do. Though they do have... downsides
- vaylian 2y ago<iframe> doesn't work inside <head>.
- taeric 2y agoTrue, 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.
- ffsm8 2y agoSure, 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
- vaylian 2y agoMany pages have the same <link rel="stylesheet"> and <script> tags which affect DOM content inside the <body>.
- endofreach 2y ago> 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.
- dfabulich 2y agoYou 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-element 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.
- jancsika 2y ago> 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!
- tannhaeuser 2y agoHTML 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.
- lenkite 2y agoYou 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://web.dev/articles/imports https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/
- vaylian 2y agoThanks! Do you know why the proposal was discontinued?
- lenkite 2y agoBecause 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.
- Lammy 2y agoFun fact: ViolaWWW (1992) had this! https://en.wikipedia.org/wiki/ViolaWWW#Firsts https://en.wikipedia.org/wiki/ViolaWWW#Firsts <INSERT SRC="a_quote.html">