- From: Elliot Jenner <void2258@gmail.com>
- Date: Sun, 10 May 2009 19:37:58 -0400
- To: www-html@w3.org
Virtually the sole purpose of the link element is to include CSS. Since it is almost never used for anything else, I consider it part of CSS for all intents and purposes. As to frames and the object usage, these have a tendency to fail at best and be outright mishandled by servers at worst. I realize that these exist, and have used them, but I have been frustrated by the spotty functionality and the difficulty of implementation. Additionally, these methods make it very difficult for beginners to perform basic tasks, discouraging them from creating pages, and are not handled very well by HTML preview systems (example:Quanta), an additional deterrent to beginners and annoyance to experienced users checking for errors. What I am suggesting for a future version (and hopefully a backport) is a simple tag command, say <include href="file" /> that takes the contents of the file in question and places it into the position it occupies, similar to what a <link href="file" type="text/css" /> does now for CSS, but without any type of formatting. In other words the parser reaches it, jumps to the other file, reads the HTML as it, then jumps back when the file ends and continues. This could also be used to import scripts that are duplicated as well. The type requirement is not as practical in this instance and could be omitted entirely if it is problematic; users advanced enough to be inserting scripts should be able to put enough in the include files to make it work on just a raw copy anyway. By integrating it into the main standard, (provided that it is emphasized so the browsers support it) you no longer have to worry about spotty implementation or support on the server side, and it does not require a large additional learning curve from casual users or beginners. There should be no need to worry about scripting or server processing for a basic task like this.
Received on Sunday, 10 May 2009 23:39:13 UTC