You can do this with XSLT, which actually works in Chrome, Firefox, and Safari, both on mobile and desktop. (I've been using it in a small site of my own for a while.) You can even do stuff like page-dependent highlighting of menu items without any JavaScript.

Granted, I'm surprised XSLT is supported at all in modern browsers, and who knows how long it will continue to be supported, but it does work now for the basic "menubar at top" use case.

Yeah, I never understood why there wasn't an <include> element in HTML, that would just paste the content of the linked document. Why wasn't such an element added in the late 90's or early 2000?

In the early days, when dynamic webpages were processed by something called CGI and even when we started using PHP, this was like 90% of the use case for doing a dynamic webpage. The last 10% might have been some sort of counter.

Server side includes were pretty common back in the day. https://en.wikipedia.org/wiki/Server_Side_Includes

They weren't common. It depended mainly of the server configuration, language used, etc. Most of the websites were static with some dynamic pages. Includes becane really popular with the rise of PHP and ASP language.

Right, but server-side includes mean unnecessary technology and bandwidth use to work around the absence of a trivial(ish, there are probably a few snags) feature.

    > I never understood why there wasn't an <include>
    > element in HTML, that would just paste the content of
    > the linked document. Why wasn't such an element added
    > in the late 90's or early 2000?

As far as I know, for SGML (and therefore old fashioned XML, too), 'include' gets realized via parsing of external &entities;. That's how the Mozilla XUL applications (Seamonkey, Firefox, Thunderbird) etc. realized localization, for example.

I don't know, when XInclude has first been ratified (the current, 2nd revision, of the spec is from 2006), but with it, a generic inclusion mechanism exists for XML, therefore also for XHTML.

With XHTML you could (in theory, as said, the spec is there) use XInclude.

    <?xml version='1.0'?>
    <html xmlns="http:www.w3.org/1999/xhtml" 
          xmlns:xi="http://www.w3.org/2001/XInclude">
      <head>        
      </head>
      <body>
        <p>120 MHz is adequate for an average home user.</p>
        <xi:include href="disclaimer.xml"/>
      </body>
    </html>

I am not quite sure, yet, how namespace mixins are handled in XHTML, I think, one must define a new schema (which, honestly is a crappy requirement and should be abandoned), effectively creating an XHTML+XInclude document type, but that may be only a real issue for strict validation.

When I first started out I was using free web hosts that didn't support server-side includes or PHP, so I ended up building my own JavaScript front end framework. Unfortunately, I didn't actually know any JavaScript, so I wrapped every line of my HTML header template in document.write() and included it in a script tag. There were some performance issues.

Why are iframes bad in this case?

In my purely HTML github pages I ended up hacking a header into the common CSS file bc that's "included" everywhere.. it's ugly and I don't think you can even put links in it... but it sorta works. If I wanna tweak it then it's all in one file

PS: this is a naiive question from a non-web dev

The fixed height requirement makes them hard to use in a responsive way.

A neat solution for this: https://github.com/davidjbradshaw/iframe-resizer

That's a lot of code just to set the height of an iframe.

> but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk,

I think you can disable that check as a command line option. I cannot check it right now since I don't have chrome installed however I think it was --allow-file-access-from-files .