Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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 at 13:13

6 Answers 6

up vote 11 down vote accepted

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.

share|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. –  Xepoch 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 at 16:41

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.

share|improve this answer
3  
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. –  Xepoch 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 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.

share|improve this answer
3  
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. –  Xepoch 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
4  
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 
</object>

I think that's implemented in most browsers.

share|improve this answer
    
Will need to try. –  Xepoch Nov 7 '10 at 15:10

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

share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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