30

I've thinking about this a lot lately. Why does HTML5 not really let you load HTML into your document to break up your HTML files?

It has support for nearly every other asset (images, videos, audio).

Yes we have iframes, embeds, and objects but they are sandboxed and don't follow the flow of the rest of the document.

I was thinking of something like:

<h2>My wonderful application</h2>

<include src = "leftPane.html" type = "text/html" />

<include src = "main.html" type = "text/html" />

<include src = "footer.html" type = "text/html" />

I would love for someone to explain this to me. In nearly every web application we make, we use some form of templating to break up our HTML, so why does HTML5 not just include it?

I'd appreciate your (flameless) thoughts.

Matt

Matt
  • 22,224
  • 25
  • 80
  • 116
  • 1
    Not an answer, but I did write a bookmarklet earlier this year which parsed [SSI](http://en.wikipedia.org/wiki/Server_Side_Includes) on pages where the functionality had been disabled on the server: [Client Side Server Side Includes](http://www.boogdesign.com/b2evo/index.php/jsssi-client-side-server-side-includes?blog=2). Several websites (eg. Twitter) are moving to a model where the [templates are defined in JavaScript](http://mustache.github.com/). Point being, there are already many ways to achieve this without adding complexity to HTML. – robertc Jul 30 '11 at 00:14
  • Thanks for the write-up. Yes, I also like the ``, but I think it should only be applied to really small, repeating fragments (ie. messages in an inbox). I just like the idea of splitting up my HTML like PHP or other templating languages do so easily. I agree that it would add complexity, but so does adding the ` – Matt Jul 30 '11 at 09:53

7 Answers7

20

As it turns out, this has come up in the WHATWG mailing lists: Client-side includes proposal: Shannon proposed exactly what you are saying, where the parser has to block while loading document fragments. Ian Hickson rejected it because the latency cost is too high. Besides, it's a simple feature that many web servers already provide, so it was deemed not worth the cost.

You may instead want to investigate using the seamless attribute of iframe, which causes a full document to be placed within the document but act like any block element (inheriting styles from the host document). I don't think it's supported by many browsers yet though.

yonran
  • 18,156
  • 8
  • 72
  • 97
  • Wow. This might be exactly what I was looking for. Do you know the browser support (if any) on the `seamless` attribute? – Matt Jul 30 '11 at 09:49
  • #Matt For browser support summary check out [link](http://www.w3schools.com/html5/att_iframe_seamless.asp) – Hatchmaster Jul 30 '12 at 10:54
4

No, each request wold not require a round trip to the server, if the contents of the templates ist constant, then it can be cached and less data has to be transferred. This is the reason why you put css and javascript into seperate files.

Peter
  • 41
  • 1
4

Similar question was asked and it is possible: HTML5 include file

Rafa's answer:

Use the object tag:

<object name="foo" type="text/html" data="foo.inc"/>

foo.inc should include valid HTML.

I tested it on Konqueror, Firefox and Chromium.

If you find it useful (I do), please upvote Rafa answer (not mine) because "it is not possible" is spreading like disease.

Community
  • 1
  • 1
greenoldman
  • 16,895
  • 26
  • 119
  • 185
  • 2
    The resulting DOM-Tree is not as if the included file was textually replaced. A whole document including and tags is inserted into the including document. – scravy Oct 21 '12 at 07:41
  • +1 BUT the [W3C validator](http://validator.w3.org/) doesn't like it and stuff after the "include" did not display (in Chrome, I did't test other browsers). W3C objected to the self closing tag. I replaced that by an ending `` and it validated and the following stuff displayed. – Mawg says reinstate Monica Feb 27 '14 at 02:26
3

HTML5 is made out of 3 components: HTML, CSS and JavaScript. So we have to use all of them to take advantage of HTML5.

External HTML code can be included in another html document using javascript. The only thing is, you have to store external code in .js file. Here is an example how to include html paragraph:

<!DOCTYPE html>
<html>
    <head>
    <title>Main Page</title>
        <script type="text/javascript" src="include_html.js"></script>
    </head>
    <body>
        <script type="text/javascript">
            paragraph();
        </script>
    </body>
</html>

Contents of include_html.js

function paragraph()
{
        document.write("<p> This is an HTML paragraph </p>");
}
Goa
  • 89
  • 5
2

Another way is to use jQuery and the tag

http://irtazaali.wordpress.com/2013/01/16/how-to-include-html-text-from-another-file-into-an-html5-page/

irtaza
  • 21
  • 1
2

Each request would of course require a round-trip to the server - can you imagine the bandwidth issues this could cause? There would be 4 request just for your snippet above (the original page + 3 includes) and then of course the browser rendering issues and then the local JS issues (i.e. at what point is the DOM loaded - do you have 4 DOMs?).

Barry Kaye
  • 7,682
  • 6
  • 42
  • 64
  • Thanks for your response, but I don't think that's any different than loading 3 images. We sprite to avoid this, but you still have the **option** to load 3 images and make 3 round-trip requests. – Matt Jul 29 '11 at 15:34
  • Oh in regards to the DOM loading.. This may be a fair point, but just as in any other templating language, the HTML is rendered first. Now maybe this does become a performance issue if the parser has to do 2 passes. Then again same thing for any web templating language rendering the html then serving it. – Matt Jul 29 '11 at 15:41
  • @Matt - what are you thoughts on each HTML include - should they be fully formed HTML docs with their own CSS and JS references? – Barry Kaye Jul 29 '11 at 15:52
  • No - more like fragments. Currently iframe, object, and embed provide a solution for fully formed HTML docs. In modern browsers you can put link and script tags wherever you please and it will render them. However, I don't think this would be advised in your fragments, just as you don't in other templating languages. – Matt Jul 29 '11 at 15:58
  • 3
    Also, there would be no round-trips if the fragment is cache-able content. – Thilo Jun 12 '12 at 06:42
0

It isn't really official yet, but it looks like Web Components, a new concept which would allow for imports similarly to how you have described, may be added to the HTML specification in the near future. It doesn't behave exactly as you asked-- as Barry Kaye pointed out this would create some issue-- but it instead takes this idea and addresses the issues.

You can see the current working draft on the concept here: http://w3c.github.io/webcomponents/spec/imports/

And I also found this article that may be easier to understand (it was for me) here: http://www.html5rocks.com/en/tutorials/webcomponents/imports/

I know this is mostly a theoretical response, but then it was also a sort of theoretical question ;).

Alex Johnson
  • 1
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient [reputation](http://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](http://stackoverflow.com/help/privileges/comment). – Onik Aug 14 '14 at 15:53