I had a question posed to me the other day by another programmer. I remember (a very long time ago) wondering the very same. Why was a browser-side include tag never considered? Or was it?

Specifically with a tag that instructed the browser to include additional HTML from other sources. e.g. <include src="http://server/foo/bar.html">. Many folks will make javascript calls and fill innerHTML to accomplish the same, when the same outside a the javascript engine could be accomplished by the browser.

It would have been painful to have nested <HTML>s <BODY>s (i.e.) but we have to consider that aspect anywhere anyway.

  • Don't external entities give you this already? Commented Sep 21, 2011 at 15:49
  • Transclusion was considered a core feature of hypertext even from its invention in the 60s. So I'm sure it was considered... Commented Sep 9, 2014 at 13:13

6 Answers 6


Am I the last person on earth who remembers the (Netscape 4-only) layer and ilayer tags?

Netscape 4 also allowed the div tag to have a src attribute, which accomplished the same thing.

Netscape submitted them to the W3C, who chose to not include them—use iframe instead.

  • I indeed remember NS4 but do not remember those features. Too bad, I still content it would save a lot of cross-browser javascript BS.
    – Jé Queue
    Commented Sep 28, 2010 at 0:31
  • I remember hating NS4 with such a passion that one of my first non-ISP email address was a free account at ihatenetscape.com. Ah, good times :D
    – wildpeaks
    Commented Dec 21, 2010 at 21:36
  • Note layers weren't quite a client side include as they still had a separate document object subject to Same Origin Policy; they were effectively a positionable iframe.
    – bobince
    Commented Sep 8, 2014 at 16:41
  • too sad, it's already 2020 and the 'src' attribute on 'div' tag is still not added. What is W3C doing?
    – Dan D.
    Commented Jun 16, 2020 at 19:49

Why was a browser-side include tag never considered? Or was it?

It was certainly requested by every newbie web author who hadn't worked out Server Side Includes yet, back in the early days on the www-html list. But in those days W3 were happy to completely ignore web author pressure.

If cross-site inclusion were allowed it would be a security disaster. You could pull in a page from the user's bank and read content from it. (Originally, DOM scripting was limited, but you could still have read from document.links, document.images, scripting functions dropped by the target page, etc. Since then you can do what you like with imported content.)

If cross-site inclusion weren't allowed... well then the feature wouldn't have any advantage over server-side includes. It'd be more, slower work for the client to do that the server could have dealt with better. Unlike <iframe>, an include would have to block page loading. SSIs would be in every way superior.

  • 6
    Actually, the client (or a proxy) could cache more efficiently, as templates (or header/footer includes) don't tend to change from page to page, meaning the user might at least be able to see part of the page whilst some server-side processing is going on. Commented Sep 25, 2010 at 10:22
  • 1
    It would do significantly more than the server. I'm not sure why it would need to block page load, it could have allowed for full page load with async content-fill. Of course it could be limited by browsers to only allow pull from originating servers or to allow a domained DOM.
    – Jé Queue
    Commented Sep 25, 2010 at 15:23
  • I don't get how it is a security disaster. I can read a bank page on server side right now and spit it out on another page - is it a disaster? Maybe, but certainly not security related one. Security disaster would be reading cookies from a different domain. Without this client side include would be exactly the same as server side one. Don't see any problem here.
    – serg
    Commented Sep 30, 2010 at 22:37
  • You can try to fetch a bank page on the server side but your request will be unauthenticated so you can't download any juicy information. A request from the client side includes cookies and HTTP authentication tokens; if you can read the response from such a request you can fully impersonate the user.
    – bobince
    Commented Oct 1, 2010 at 12:44
  • @bobince: Is there any reason that the request on the client side would have to include cookies and HTTP authentication tokens? The primary usage scenario I would see for client-side includes would be to improve caching of static page content. If sixteen pages all include the same header and footer, using a client-side include would increase the time required to load the first, but reduce the time to load the remaining fifteen. The usage cases where the include would be the most helpful would be precisely those where the data to be "included" would be static and thus not need...
    – supercat
    Commented Sep 8, 2014 at 16:07

They did. It became the <frameset> tag. Not long after, they added the <iframe> tag.

Most of the early web servers supported server-side includes, so a client-side textual include was likely thought to be unnecessary, given that the same functionality was available also with frames.

  • 5
    Not really frames serve a very different purpose than inclusion. Plus the restrictions on iframes especially in object set size surely could not have thought to take its place.
    – Jé Queue
    Commented Sep 25, 2010 at 4:56
  • 5
    I disagree - I think that's exactly what frames do. What else are frames for except including more HTML? Commented Sep 25, 2010 at 5:34
  • 5
    Frames are including HTML in frames, not directly -- this is the difference.
    – mbq
    Commented Sep 25, 2010 at 10:12
  • 4
    @Xepoch: ... With an <iframe>. That's what it's for. It's really not much different from a <div> with overflow:auto;
    – greyfade
    Commented Sep 25, 2010 at 18:06
  • 3
    The <iframe> element basically says "load the specified html document and stick it here". You would choose it instead of ajax if you want the document to be loaded immediately, not on a javascript call... Frames are NOT windowing layout of HTML. Div, p, br - these are all elements used for layout. You don't use frames for layout (or you shouldn't anyways). Commented Sep 29, 2010 at 5:53

Variants on an <include> tag were indeed considered in the early history of HTML, but they never got very far.

  • 1
    However the semantics of that <include> tag were similar to those of today's frame/iframe/object - it would include a html document, and not just snippets of text/code or random tags as C's #include would. Commented Aug 26, 2018 at 20:53

Object still renders in a frame and you have no DOM access to "data." What developers should have been given years ago is a way to include snippets with a simple tag. Even if this tag had domain sandbox restrictions it would be pretty useful to compartmentalize features, improve maintenance and take advantage of browser caching.

I know there are plenty of good jquery plugins that do this and lots of server side scripts, but there is no good reason to not support such a tag. IMO its a good question "Why no client-side include tag?"

If you like jquery here is a good client side include script: inc: A super-tiny client-side include JavaScript jQuery plugin

  • Your reply is the only one that seems to have hit the nail on the head. Are you thinking of something like #include in C? This is exactly the kind of thing "client-side include" means to me - a facility for including arbitrary HTML snippets (rather than entire HTML documents) within an HTML document as integral document content. Though it could be designed as an integral feature of HTML rather than as a pre-parsing stage - the asker's suggested <include src="..."> syntax would fit right in with this.
    – Stewart
    Commented Oct 24, 2015 at 11:36
  • The problem with adding it now would be backward compatibility. Of course, this doesn't explain why it wasn't included in the original design of HTML.
    – Stewart
    Commented Oct 24, 2015 at 11:37
  • It could alternatively have been designed as a feature of SGML/XML more generally....
    – Stewart
    Commented Oct 24, 2015 at 11:37
  • even the javascript solutions require a server. We need a solution that does not require a server. Why does this not exist yet? It just makes extra work for developers. Just give us html snipit injection without need for server. Everybody wants it. Commented Jul 16, 2022 at 10:15

Have you tried

<object  type="text/html" data="page.html" height="500" width="500">
What I see if that didn't work 

I think that's implemented in most browsers.

  • Will need to try.
    – Jé Queue
    Commented Nov 7, 2010 at 15:10
  • 1
    interesting, but the contents inside 'page.html' are isolated (iframe), can't access anything outside
    – Dan D.
    Commented Jun 16, 2020 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.