3 ms·
Although not vanilla HTML, server side includes are the closest to this that we've got. I use them quite extensively. This is basically what my boilerplate look
by VoodooJuJu 4y ago
Although not vanilla HTML, server side includes are the closest to this that we've got. I use them quite extensively. This is basically what my boilerplate looks like:
<!DOCTYPE html>
<html lang="en" class="no-js">
<head>
<!--#include virtual="/ssi/head.html" -->
<title></title>
<meta name="description" content="">
</head>
<body>
<header>
<!--#include virtual="/ssi/header.html" -->
</header>
<main>
</main>
<footer>
<!--#include virtual="/ssi/footer.html" -->
</footer>
</body>
</html>
I'll put all my favicon, CSS, and other common head data in the /ssi/head.html file. Nice and simple and good enough for me. Can make it even more minimal by moving the <header> and <footer> tags into their respective SSI files.
- fergie 4y agoUnfortunately SSIs dont work on s3 and some other plaforms, thereby negating their utility for running static sites on CDNs or keystores. But YES- why isn't there an SSI equivalent in the HTML spec?
- extra88 4y ago> why isn't there an SSI equivalent in the HTML spec? Because HTML Imports died in the spec drafting process. Unless you want a client-side SSI equivalent that doesn't require any JavaScript, HTML Imports wasn't that. I'm not aware of an alternative proposal that doesn't. https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/ https://webmasters.stackexchange.com/questions/127482/on-what-specific-grounds-were-html-imports-rejected-deprecated-and-removed https://webmasters.stackexchange.com/questions/127482/on-wha...