- From: Dustin Boyd <rpgfan3233@gmail.com>
- Date: Sat, 9 May 2009 14:28:57 -0500
- 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 UTC