- 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