5 ms·

Why couldn't basic templating or includes have been built in HTML natively? It's stupid that you have to use a static generator, client-side rendering, or dyna

by Evidlo 4y ago

Why couldn't basic templating or includes have been built in HTML natively? It's stupid that you have to use a static generator, client-side rendering, or dynamic content generation just to get a website with consistent headers/footers on all pages. I dream of being able to author web content with just a text editor.

Semaphor 4y ago
Frames work for that, but are obviously deprecated. Slightly more server dependent, but you could use SSIs [0] for that. [0]: https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
- Evidlo 4y ago
  The problem is that frames live in a separate DOM, so content inside them doesn't flow/resize with the page.
_han 4y ago
This is actually part of HTML, but the API is a bit clumsy: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
- Evidlo 4y ago
  If we're allowing Javascript in the picture, isn't this something that's always been possible?
tannhaeuser 4y ago
> Why couldn't basic templating or includes have been built into HTML natively? Because HTML started life as an SGML application/vocabulary, and with SGML having entities (and link process declarations/stylesheets) for exactly these purposes, there was no need to invent HTML ad-hoc mechanisms. SGML templating based on SGML LINK works in a push (event-driven) style, with fully type-checked and HTML-aware semantics, quite different from your typical pull style embedding of whole programming languages that spit out unescaped strings ([1]). Of course, browsers never came around to implement even basic SGML features such as entities (except for character entity references), and by 1994 or so, JavaScript was already introduced, making any HTML evolution inessential by introducing a Turing-complete language into the mix. [1]: http://sgmljs.net/docs/templating.html http://sgmljs.net/docs/templating.html

by Evidlo 4y ago

Semaphor 4y ago

Frames work for that, but are obviously deprecated. Slightly more server dependent, but you could use SSIs [0] for that. [0]: https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes

Evidlo 4y ago
The problem is that frames live in a separate DOM, so content inside them doesn't flow/resize with the page.

_han 4y ago

This is actually part of HTML, but the API is a bit clumsy: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

Evidlo 4y ago
If we're allowing Javascript in the picture, isn't this something that's always been possible?

tannhaeuser 4y ago

> Why couldn't basic templating or includes have been built into HTML natively? Because HTML started life as an SGML application/vocabulary, and with SGML having entities (and link process declarations/stylesheets) for exactly these purposes, there was no need to invent HTML ad-hoc mechanisms. SGML templating based on SGML LINK works in a push (event-driven) style, with fully type-checked and HTML-aware semantics, quite different from your typical pull style embedding of whole programming languages that spit out unescaped strings ([1]). Of course, browsers never came around to implement even basic SGML features such as entities (except for character entity references), and by 1994 or so, JavaScript was already introduced, making any HTML evolution inessential by introducing a Turing-complete language into the mix. [1]: http://sgmljs.net/docs/templating.html http://sgmljs.net/docs/templating.html