- From: Roland Bluethgen <calocybe@web.de>
- Date: Mon, 11 May 2009 14:03:37 +0200
- To: Elliot Jenner <void2258@gmail.com>
- CC: www-html@w3.org
Elliot Jenner wrote: > 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. This is a misunderstanding at your side. The link element doesn't /include/. It carries /information about a relationship/ to other documents. So to speak, other documents are /assigned/ to the document in question. It is entirely up to the user agent how to respond to getting knowledge of such relationship. In the case of CSS and a UA capable of processing CSS, it would normally request the CSS document and apply its rules to the representation of the document. Aryeh has informed you about other widely deployed uses of the element. > 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. I notice the absence of the rel attribute in your example, again indicating the misunderstanding of the link element. The style sheet assignment is not denoted by type="text/css", it is denoted by naming the kind of relationship to the CSS document, i.e. rel="stylesheet". Regarding the introduction of some kind of inclusion mechanism to HTML, I predict the story would go like this: After agreeing on an <?include?> processing instruction, the next inevitable extensions would be conditional statements and variables, because people feel the urgent need to implement hierarchical menus with the current item highlighted. (But we already have that, it is called server side includes, only that SSI is a server-side technique.) Then people want to more cleanly separate content and presentation and thus need a variety of loops and the possibility of loading data files or querying an RDBMS. (Again we have that, it's called PHP, and it also works without a server environment.) Soon we would have another full-blown programming language -- or several such languages, because people tend to develop strong feelings about what would be the right[tm] syntax for all this stuff. So we would separate the programming from HTML again and only do some kind of designating or referencing within HTML. Yet again, we already have this, just in the other direction: we would designate HTML chunks and programming statements from within a build provision called Makefile. And so I approach the practical part of your question (how to get your problem solved). I suggest you deploy some kind of preprocessor in conjunction with the build system of your choice. As for the preprocessor, you could use CPP, which you already know from C++, but I'm afraid it is syntactically unpleasant within HTML. A good choice imho would be PHP. Indeed, this task is the original purpose of PHP (and imho the only application which it is good for). It has a simple C-like syntax and all the control structures you need. And an include statement, too. Then there was a very interesting project called Website Meta Langauge, featuring file inclusion, macro expansion, embedded Perl and output splitting. Unfortunately it appears to have been abandoned. When I once tried, I didn't even manage to make it build. Otherwise this would be my favourite for the task. http://thewml.org/ As for the build system, there's an abundance available these days. http://en.wikipedia.org/wiki/List_of_build_automation_software At the end of the day, HTML is not meant to be a programming language, it's meant to markup text.
Received on Monday, 11 May 2009 12:04:58 UTC