Re: Missing Functionality: Include

I know it (may) seems very bad solution, but it's possible to make an "incude" in JavaScript, which is the client-side scripting language (which HTML is not).
It is a good way to save client-server transfer because you can cache small parts of a web page and don't send them after that to the same user.

They are two way to do it : 
* Synchronal system

<script><!--
   (function() {
       var xhr = new XMLHttpRequest();
       xhr.open("GET", "/menu.part.html", false);
       xhr.send(null);
       document.write(xhr.responseText);
   })();
--></script>

If you use a good cache policy on your server for the specified "part.html" file, you can save the transfer of the menu (except the first time the user loads your page).
But it still have the problem it can slow down your page's loading the first time the user loads it.

* Asynchronal system 

<div id="menu"><span class="loading">Loading...</span></div>
<script><!--
   (function() {
       var xhr = new XMLHttpRequest();
       xhr.open("GET", "/menu.part.html", true);
       xhr.onreadystatechange = function() {
          if (xhr.readyState==4) { document.getElementById("menu").innerHTML = xhr.responseText; }
       }
       xhr.send(null);
   })();
--></script>

It have the advantage it don't make your page's first load slower, but it have the disavantage that the menu can be not present during some time the first time you use the page.

Depending on the size of the data you want to cache, using one method or the other can be envisaged.

Regards,
Fremy



From: Molte 
Sent: Sunday, May 10, 2009 11:07 AM
To: Dustin Boyd 
Cc: HTML Working Group Discussion Mailing-List 
Subject: Re: Missing Functionality: Include


When using frames the URL in the browser address bar will not change when you navigate around the site. Therefore a specific page cannot be identified by the URL. So using frames would probably not be a good idea.

Then, of course, you have iframes. But with an iframe you restrict the content of the included page to a specific area - that is not to keep layout and structure separated.

You also refer to a solution using the object element, though, it would need some scripting. It should be possible to include a page without.

All the possible solutions, you refer to, are certainly usable, but when you think about it: Who uses them? Doesn't everybody use a server-side feature for the thing instead? There is probably an explanation to that.

Anyway, wouldn't you be able to include a page using the HTML 5 embed tag (I ask because I do not know)?
----
Molte


2009/5/9 Dustin Boyd <rpgfan3233@gmail.com>

  On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@gmail.com> wrote:
  >
  > Coming from programming languages like C++ and Python, I naturally
  > expected that it would be similarly simple to move redundant parts
  > of the page into external files and then include them back in. After
  > extensive searching, I determined that this basic functionality is
  > missing from the language, and requires such hefty workarounds as
  > server-side-scripting or PHP. It should not be necessary to go to a
  > completely different language to perform such a necessary task,
  > particularly languages that require the added complication of a web
  > server just to see if your code is functioning properly, and the
  > added worry that some servers may not support the scripting.
  >
  > Am I alone in wishing for a simple <include url('file.html')/>
  > element or something similar that allows this to be accomplished
  > easily?


  You must not have known about frames [1], something that HTML has had
  for a long time in one form or another.  The exact same technology
  also exists in XHTML 1.0 via the frameset DTD [2], albeit with a
  couple of changes that affect XHTML in general rather than frames
  specifically.  Another possibility is the IFRAME element [3].  The
  OBJECT element [4] works too, with some minor caveats in the area of
  client-side scripting such as JavaScript.


  > In my opinion this is a completely basic function that any language
  > should have. How did CSS, which was developed later, obtain the
  > <link> tag, meanwhile the older HTML standard still lacks it?


  Actually, the LINK element is a part of HTML (and XHTML) [5].  It is
  simply used to create a relationship between an HTML document and a
  CSS document.  CSS defines style sheet rules; HTML/XHTML defines
  elements.  They are completely different languages, though it may
  appear as if they all go together because they're used together so
  often.


  > Particularly on a website, there will always be bits of code that
  > are common to all the various pages that make it up, for example the
  > navigation and copy write/contact code.


  This is why frames are a great tool when you don't have more useful
  solutions like server-side scripting/programming available.  However,
  there are usability issues with frames, something that server-side
  scripting fixes (or server-side includes at the very least).  I've
  personally never used the OBJECT element as a replacement for frames,
  but I haven't heard about any bad experiences with it other than
  scripting as previously mentioned.  Then again, with as much
  JavaScript as there is in use these days, I am not surprised that I
  hear so little about replacing frames using OBJECT.  On the other
  hand, it has been over a year since I've heard anything about OBJECT
  as a replacement for IFRAME, which is already a replacement for the
  not-very-usable HTML framesets that I pointed out at first.

  You can see a live example of using OBJECT as an alternative to IFRAME
  [6], though I'm not exactly sure how old (or reliable) it is.  Again,
  there might be scripting issues so stay guarded.

  [1] - http://www.w3.org/TR/html4/present/frames.html
  [2] - http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset
  [3] - http://www.w3.org/TR/html4/present/frames.html#h-16.5
  [4] - http://www.w3.org/TR/html4/struct/objects.html#h-13.3
  [5] - http://www.w3.org/TR/html4/struct/links.html#h-12.3
  [6] - http://intranation.com/test-cases/object-vs-iframe/