You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect I'm opening a huge can of worms here and that this has been discussed numerous times over the years. However, since I couldn't find any of these discussions after spending over half an hour searching, I decided to open one. After all, what's the worst thing that could happen? 😁
Currently, even the simplest templating, such as headers and footers across multiple pages of a static website, require server-side code or build tools, both of which which are complicated for non-developers and take time for everyone. JS solutions exist, but this reduces indexability and makes essential parts of the website content very fragile.
This proposal is for an HTML element that accepts an src attribute, asynchronously fetches the content (following usual CORS rules) and embeds it in the page's DOM tree, executing any <script> elements. Since <template> is taken, one potential name (for the sake of discussion) could be <include>. Alternatively, <link rel="html">, so that it can be used in the <head> too without the issues a new element would introduce.
Not another <iframe seamless>!
This element transcludes the content of the linked HTML document. This means better performance (no multiple documents and window contexts), and simpler CSS. This essentially mimics how sever-side includes work.
Why not use a custom element or JS?
See comment re:JS solutions above. Several indexers and server-side renderers do not process JavaScript. Also, JS is inherently fragile, and this is needed for essential parts of a website's content.
Furthermore, a declarative solution has some accessibility benefits, since browsers could expose UI to skip certain templates (e.g. a website header with no "skip to content" link).
Questions that need to be answered
Several things need to be ironed out for this to happen, but I firstly wanted to gauge interest and see if there are any major implementation obstacles I'm missing (since this seems like very low-hanging fruit, so there must be a reason it doesn't exist).
Does the <include> element stay in the DOM?
Regarding how the transclusion happens, I see three possibilities, each with its own pros and cons:
The <include> element remains in the DOM and the fetched HTML is added as a child
The <include> element remains in the DOM and the fetched HTML is added after it (akin to document.write() in <script>)
The <include> element is replaced by the fetched HTML.
Does DOMContentLoaded wait for the content to load? What about the load event?
It seems reasonable that the answer is no and yes respectively, but probably another thing to discuss.
The text was updated successfully, but these errors were encountered:
@LeaVerou , while I have not seen such implementation published yet, there are multiple JS libs with similar functionality, dojo's ContentPane for example. I have made such few times. The latest is WebComponent implementation: <embed-page src="url" />. On earlier stages it did not have CSS and JS scope insulation as you wanted. Now scope is enforced and in the future different scope insulation levels are planned, including 'none' - matching embedding content into page without insulation as you wanted.
I suspect I'm opening a huge can of worms here and that this has been discussed numerous times over the years. However, since I couldn't find any of these discussions after spending over half an hour searching, I decided to open one. After all, what's the worst thing that could happen? 😁
Currently, even the simplest templating, such as headers and footers across multiple pages of a static website, require server-side code or build tools, both of which which are complicated for non-developers and take time for everyone. JS solutions exist, but this reduces indexability and makes essential parts of the website content very fragile.
This proposal is for an HTML element that accepts an
src
attribute, asynchronously fetches the content (following usual CORS rules) and embeds it in the page's DOM tree, executing any<script>
elements. Since<template>
is taken, one potential name (for the sake of discussion) could be<include>
. Alternatively,<link rel="html">
, so that it can be used in the<head>
too without the issues a new element would introduce.Not another
<iframe seamless>
!This element transcludes the content of the linked HTML document. This means better performance (no multiple documents and window contexts), and simpler CSS. This essentially mimics how sever-side includes work.
Why not use a custom element or JS?
See comment re:JS solutions above. Several indexers and server-side renderers do not process JavaScript. Also, JS is inherently fragile, and this is needed for essential parts of a website's content.
Furthermore, a declarative solution has some accessibility benefits, since browsers could expose UI to skip certain templates (e.g. a website header with no "skip to content" link).
Questions that need to be answered
Several things need to be ironed out for this to happen, but I firstly wanted to gauge interest and see if there are any major implementation obstacles I'm missing (since this seems like very low-hanging fruit, so there must be a reason it doesn't exist).
Does the
<include>
element stay in the DOM?Regarding how the transclusion happens, I see three possibilities, each with its own pros and cons:
<include>
element remains in the DOM and the fetched HTML is added as a child<include>
element remains in the DOM and the fetched HTML is added after it (akin todocument.write()
in<script>
)<include>
element is replaced by the fetched HTML.Does
DOMContentLoaded
wait for the content to load? What about theload
event?It seems reasonable that the answer is no and yes respectively, but probably another thing to discuss.
The text was updated successfully, but these errors were encountered: