SGML (ISO 8879), the markup meta-language on which HTML is based, has that, as well as many other things, such as type-checked templating.
Hence HTML as a mere vocabulary making use of SGML's facilities didn't need to define its own ad-hoc mechanism.
Btw the <?php ...> construct is also derived from SGML. In SGML terms it's a "processing instruction" rather than an "entity reference", the latter being the basic means for content inclusion.
It would tie in an additional feature with potential future incompatibilities, and it moves insecurities in templates to the client runtime where they’re more dangerous than compile/interpret time.
Eg some template feature creates a security issue and has to be disabled, which invalidates all the old HTML that used it.
There’s also just not a super great reason to do it. It’s not all that different from pre-templating like Hugo or doing it server-side like Django. You get to offload some compute, but HTML templating isn’t usually the bottleneck.
It's a markup language for documents. If you enable templating devs are then going to ask for more. Eventually it will end up turing complete. Such is the development arc of a lot of languages.
It's almost a meta-slippery-slope fallacy, in that the specific slope is not specified; only the existence of the slope and its slipperiness is asserted.
SGML (ISO 8879), the markup meta-language on which HTML is based, has that, as well as many other things, such as type-checked templating.
Hence HTML as a mere vocabulary making use of SGML's facilities didn't need to define its own ad-hoc mechanism.
Btw the <?php ...> construct is also derived from SGML. In SGML terms it's a "processing instruction" rather than an "entity reference", the latter being the basic means for content inclusion.
We do.
https://www.w3.org/TR/xinclude/
https://www.w3.org/TR/xinclude-11/
Nice idea!
https://web.dev/articles/imports
Been there, tried that.
Introduced in 2014 (Chrome 36) Deprecated 2018 (Chrome 70) Retired 2019 (Chrome 73)
You might be interested in https://github.com/WICG/declarative-partial-updates
In the old days, we used to emulate this with a <script> tag that did a document.write ... yes, very hacky.
<?php include "header.html" ?>
SSIs are not widely supported any more, and were never a part of the HTML standard
(but yes- I used these a lot like 25 years ago)
From what I can tell, apache mod_include and nginx SSI are still included by default?
Yes, but then you need php
Why is there no direct support for templating in HTML itself?
It would tie in an additional feature with potential future incompatibilities, and it moves insecurities in templates to the client runtime where they’re more dangerous than compile/interpret time.
Eg some template feature creates a security issue and has to be disabled, which invalidates all the old HTML that used it.
There’s also just not a super great reason to do it. It’s not all that different from pre-templating like Hugo or doing it server-side like Django. You get to offload some compute, but HTML templating isn’t usually the bottleneck.
It's a markup language for documents. If you enable templating devs are then going to ask for more. Eventually it will end up turing complete. Such is the development arc of a lot of languages.
> If you enable templating devs are then going to ask for more
This might be the worst argument for anything I've read this week, there's got to be a name for this logical fallacy
A "slippery slope" fallacy might be what you're thinking of.
It's almost a meta-slippery-slope fallacy, in that the specific slope is not specified; only the existence of the slope and its slipperiness is asserted.
Can I introduce you to iframes? Clunky but they do exactly what you are asking for.
and in a much safer way, sandboxed.