W3C home > Mailing lists > Public > www-html@w3.org > May 2009

Re: Missing Functionality: Include

From: Dustin Boyd <rpgfan3233@gmail.com>
Date: Sat, 9 May 2009 14:28:57 -0500
Message-ID: <ef7a0f3a0905091228v27983b96jcf630758c013d399@mail.gmail.com>
To: Elliot Jenner <void2258@gmail.com>
Cc: www-html@w3.org
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/
Received on Saturday, 9 May 2009 19:29:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:15 GMT