I say tragically, because XSLT was indeed the only sort-of workaround that was available for templating in the browser, even if it was limited to v1 rather than the much more useful v2 and v3.
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.
https://web.dev/articles/imports
Been there, tried that.
Introduced in 2014 (Chrome 36) Deprecated 2018 (Chrome 70) Retired 2019 (Chrome 73)
Why is there no direct support for templating in HTML itself?
This might be the worst argument for anything I've read this week, there's got to be a name for this logical fallacy
It's a repeated observation that keeps coming true. DSLs have a tendency to become turing complete over time.
- It happened to wikipedia's templating language
- It happened to PHP
- It happened to mod_rewrite
- It happened to server-side includes
- etc...
It just keeps happening.
In fact it's such a problem with infrastructure teams that use yaml/json configs that you see a lack of turing-completeness being advertised as a feature (see Dhall configuration language).
But "we can't give something to users because otherwise they'll ask for other stuff" is not an argument. They're _already_ asking for stuff (templating) anyway. No one is suggesting that shutting users up is a reason to implement templating, it's the trade-offs of this feature that are debated. And if it gets implement then yes, users will certainly ask for more features, the trade-offs of which can be debated.
If you think that the line for HTML features is where we already are, you can present your arguments for why (tbh I'll probably agree). But "if you enable templating devs are then going to ask for more" isn't one.
If the other 10% of features are implemented, then any further change makes the DSL turing complete.
It's not even really `if` by itself, conditionals are good enough. Templates with for loops that can check if an index is the first or last can implement if statements. Also templates that can nest other templates recursively with a max recursion depth can also implement if.
You have to go out of your way to avoid turing completeness if you want to avoid a complexity explosion.
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.
No offense but this is a bit of a non-argument that could be applied to just about any development in HTML.
> There’s also just not a super great reason to do it.
Most web dev frameworks exist in large part to solve the problem of templating. (yes, they do other stuff, but templating is the central problem that they are solving)
HTML is actually shockingly backwards compatible. I very rarely see pages so old they won’t render. The main exception is basically exactly what I’m talking about: Flash and ActiveX, that had to be abandoned for security (and some poorly advised iframe stuff).
> Most web dev frameworks exist in large part to solve the problem of templating.
This might be an agree to disagree area. Most web dev frameworks I’ve seen exist to make dealing with state easier. They do templating because you have to put the state somewhere, but the magic is all in the state.
There are some that only do templating, but they’re pretty rare. Hugo or Jekyll come to mind, though “web dev framework” is probably overselling them.
There are also web components, which sound vaguely like what you’re talking about. They’re not crazy popular, but they exist and work. The security boundaries make it kind of a nightmare, I remember having to do something weird to inject Tailwind into them because they’re isolated from global CSS. The kind of things you have to do when securing templates at runtime instead of compile time.
<!-- #include file="header.html" -->
(but yes- I used these a lot like 25 years ago)