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? – Peter Taylor Sep 21 '11 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... – Alex Feinman Sep 9 '14 at 13:13

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.

| improve this answer | |
  • 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 Sep 28 '10 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 Dec 21 '10 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 Sep 8 '14 at 16:41
  • too sad, it's already 2020 and the 'src' attribute on 'div' tag is still not added. What is W3C doing? – datdinhquoc Jun 16 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.

| improve this answer | |
  • 5
    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. – Alan Pearce Sep 25 '10 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 Sep 25 '10 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 Sep 30 '10 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 Oct 1 '10 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 Sep 8 '14 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.

| improve this answer | |
  • 4
    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 Sep 25 '10 at 4:56
  • 5
    I disagree - I think that's exactly what frames do. What else are frames for except including more HTML? – Jaco Pretorius Sep 25 '10 at 5:34
  • 5
    Frames are including HTML in frames, not directly -- this is the difference. – mbq Sep 25 '10 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 Sep 25 '10 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). – Jaco Pretorius Sep 29 '10 at 5:53

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.

| improve this answer | |
  • Will need to try. – Jé Queue Nov 7 '10 at 15:10
  • interesting, but the contents inside 'page.html' are isolated (iframe), can't access anything outside – datdinhquoc Jun 16 at 19:53

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

| improve this answer | |
  • 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. – Tomáš Pospíšek Aug 26 '18 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

| improve this answer | |
  • 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 Oct 24 '15 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 Oct 24 '15 at 11:37
  • It could alternatively have been designed as a feature of SGML/XML more generally.... – Stewart Oct 24 '15 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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