NO! NOT HTML! See below.
* the reasoning is
* as follows:
* 1) server side includes are only activated for files with some file
* extension.
* This is a realy good idea! It save many cpu cycles. it even recognizes
* certain files eg having specified the 'extension' as index.html the
* deamon tries to do server side includes for every file ending in
* 'index.html' . I'm not sure if this was the intended behaviour, but it
* is good for me.
This is the intended behavior. There is a far more important distinction
being made here than you may realize. You are telling the server that
certain files are of a special format, text/x-server-parsed-html. This is an
internal representation that IS NOT HTML. It is similar to HTML, and
translates into HTML, but it is not HTML.
* 2) the include syntax is weird. The idea of using comments for it is the one
* I think is unnesseccary and unwanted. what's wrong with a element
* of <include "ape.html"> Nothing it seems to me. every browser is
* expected to ignore it when not recognized (in case it does and up
* in the client, without being included(this was the argument to use
* the comment element for it)).
What about the element INCLUDE on the client side that may (or hopefully
not) appear in the future? FLASTMOD with a URL?
You are also now requiring every HTML DTD to have special cases for things
that no browser should ever see. There is no reason to use HTML like tags.
The reason that the activation characters happen to be those that surround
SGML comments is so that in the event that this internal representation
should fall into external parsing hands, the extra directives will be
ignored without conflicting with existing HTML tags that may have the same
name.
* Also the include could be handle by either the client or the server
* (ofcourse you want to include it by the server, but it's the fact
* that one can use the same syntax for it... <include "some url"> could
* be a file from any machine, but could be included by the server before
* sending it to the client if it so happens that the file is located
* on the same server *and* the file extension matches the one defined
* under (1)).
This is fine for file includes but file includes are but one feature among
many that can't be done on the client side. Further, I would argue that
making sure that the ape.html referenced on the server is the same as the
ape.html referenced by the client expanding an include is far too difficult.
* I really don't want to stress this to much (the harm being done already),
* but please keep don't keep adding definitions of new elements or pseudo
* elements (hidden in a comment) were other elements can serve the same
* purpose
Again, I don't see what this has to do with HTML.
* Please don't flame me with html editors will do it for you.
* (they won't for me)
*/
No flame, I'm just trying to clear things up a bit. HTML editors will do it
for some later on, all they have to do is insert an HTML comment which
happens to have significance to the server.
--Rob