171–180 of 367 posts
You can get JS-free, client-side include functionality if you're willing to wrap your HTML in XML. Here is a demo: https://github.com/Evidlo/xsl-website
How well supported is XSLT in modern browsers? What would be the drawbacks of using this approach for a modern website?
If main.html includes child/include1.html and child/include1.html has a link src="include2.html" then when the user clicks the link where does it go? If it goes to "include2.html", which by the name was meant to be included, then that page is going to be missing everything else. If it goes to main.html, how does it specify this time, use include2.html, not include1.html?
You could do the opposite, you can have article1.html, article2.html, article3.html etc, each include header.html, footer.html, navi.html. Ok, that works, but now you've make it so making a global change to the structure of your articles requires editing all articles. In other words, if you want to add comments.html to every article you have to edit all articles and you're back to wanting to generate pages from articles based on some template at which point you don't need the browser to support include.
I also suspect there would be other issues, like the header wants to know the title, or the footer wants a next/prev link, which now require some way to communicate this info between includes and you're basically back to generate the pages and include not being a solution
I think if you work though the issues you'll find an HTML include would be practically useless for most use cases.
There are all kind of issues with HTML include as others have pointed out If main.html includes child/include1.html and child/include1.html has a link src="include2.html" then when the user clicks the link where does it go? If it goes to "include2.html", which by the name was meant to be included , then that page is going to be missing everything else. If it goes to main.html, how does it specify this time, use inclu…
-- index.html
Hello includes
-- header.js
document.currentScript.outerHTML = `
Header
`
-- footer.js
document.currentScript.outerHTML = `
Footer
`
It was not in the early spec, and seems someone powerful wouldn't allow it in later. So everyone else made work arounds, in any way they could. Resulting in the need being lessened quite a bit.
My current best workaround is the tag, which has a few better defaults than iframe. If you put a link to the same stylesheet in the include file it will match pretty well. Size with width=100%, though with height you'll need to eyeball or use javascript.
Or, Javascript can also hoist the elements to the document level if you really need. Sample code at this site: https://www.filamentgroup.com/lab/html-includes/
This is the closest we can do today: -- index.html Hello includes -- header.js document.currentScript.outerHTML = ` Header ` -- footer.js document.currentScript.outerHTML = ` Footer ` Scripts will replace their tags with html producing a clean source, not pretty but it works on the client
For /footer.html
But then you probably might as well use server side includes
This was the rabbit hole that I started down in the late 90s and still haven’t come out of. I was the webmaster of the Analog Science Fiction website and I was building tons of static pages, each with the same header and side bar. It drove me nuts. So I did some research and found out about Apache server side includes. Woo hoo! Keeping it DRY (before I knew DRY was a thing). Yeah, we’ve been solving this over and ove…
> Why not have a simple client side method for this? Like writing a line of js?
If internally this gets optimized to a simple I/O operation (which it should) then why add the JS indirection in the first place?