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

Re: Missing Functionality: Include

From: Roland Bluethgen <calocybe@web.de>
Date: Mon, 11 May 2009 14:03:37 +0200
Message-ID: <4A081419.6000009@web.de>
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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:22 UTC