框架
框架曾经是要走的路,但随着时间的流逝,由于某种原因,它们已经不再受到开发人员的青睐——请注意这篇2006 年的文章!
幸运的是,您似乎赞成避免使用框架:)
基于 JavaScript 的 SSI
其次,服务器端包含 (SSI) 或其他一些基于服务器的“包含”优于 JavaScript,尽管我承认这不一定是“纯”HTML/JS/CSS 解决方案。
SSI 声明的格式如下:
<!--#include virtual="../quote.txt" -->
http://www.htmlgoodies.com/beyond/webmaster/article.php/3473341/SSI-The-Include-Command.htm
有很多答案反映了这种关于 SO 的观点——例如,搜索中出现的前三个是
here、
here和
here ...
请注意,最后一个接受的答案是推荐 JS 解决方案,但最后一段陈述了对服务器端的偏好。
编译你的 HTML 代码(我的首选)
我需要创建一个“纯”HTML/CSS/JS 网站已经有一段时间了,但是这样做时,我的偏好是保持代码模块化并在部署之前“编译”HTML。
尽管在部署之前需要做一些额外的工作,但它会产生“最纯粹”的输出,以便在部署的代码中使用。您像往常一样编写代码,使用一点魔法来指示您想要包含的内容和位置,然后将此代码“编译”成部署到您网站上的标准 HTML/CSS/JS 文件。
这带来了使用模板化页眉/页脚/菜单栏/侧边栏文件的便利性和简单性,但需要事先编译 HTML 代码。
SASS 使用 Ruby on Rails 来执行此编译。不幸的是,在这个特定的时刻,它的 HTML 等价物的引用正在逃避我,所以我将在重新定位它时更新我的答案。