After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec.
Look at the options for including HTML fragments in web pages:
1. Complex client-side react/vue/etc,
2. A server language ,
3. A build-step including a non-spec bundler/packer,
4. A `<remote-fragment src="..." />
My point is that webcomponents make quite a lot of complicated things redundant for particular use-cases. As time goes on I see the fat front-end frameworks having more of their functionality being replaced with less complex (to use) custom elements.
(Hence my experiments with value propagation using custom elements)
<!--#include virtual="/footer.html" -->
Tbf, you did specify 'server language' in a post further up the comment chain, but the the thing is that it doesn't have to be much more complicated that SSI -- assuming it's available for your deployment target, of course.(SSI obviously does not require JavaScript.)
Sure, you can use $A if using $B server, or use $C when using $D language, or use $E when using $F framework, or use $G when using $H reverse-proxy, or use $I when using $J CDN, or use $K when using $L hosted cloud service ...
Or you can just use what's in the specification which works on all of the above, but won't work on clients with Javascript disabled.
It's a "choose your poison" scenario.
You could querySelectorAll and check the src attribute etc, then fetch the content put it in the innerHTML.
<remote-fragment src="https://..." />
<script>
document.querySelectorAll("remote-fragment").forEach(async (el) => {
const src = el.getAttribute("src");
const result = await fetch(src).then((res) => res.text());
el.innerHTML = result;
});
</script>
Or if you want to react to any such component inserted at times down the line or src attribute changes, you could use MutationObserver.For example it won't work recursively when a fetched fragment has fragments of its own.
Or when the js snippet loads before some fragment element is loaded (say, from a DOM update).
The nice thing about custom elements is that you get to treat them exactly like normal elements.
<body>
<script>
const onRemoteFragmentMount = async (el) => {
const src = el.getAttribute("src");
const result = await fetch(src).then((res) => res.text());
el.innerHTML = result;
};
const callback = (mutationsList, observer) => {
for (let mutation of mutationsList) {
if (mutation.type === "childList") {
mutation.addedNodes.forEach((node) => {
if (node.tagName === "REMOTE-FRAGMENT") {
onRemoteFragmentMount(node);
}
});
}
}
};
const observer = new MutationObserver(callback);
const bodyElement = document.querySelector("body");
observer.observe(bodyElement, {
childList: true,
subtree: true,
});
</script>
<remote-fragment src="..." />
</body>