> The main problem I see with this solution is that it is HTTP specific.
> HTML is an SGML application. I believe it is best that a solution is
> targeted more in the SGML realm so authors have more control on how a
> document will appear based upon a client's conformance level. Plus not
> all HTML documents are served via HTTP.
The concern about not serving via HTTP is valid, but I think it's
smaller than the other concerns. Requireing the document designers
(note that I tend to use the word designer, not author) to keep
track of which features are or are not supported by different
browsers, and keep track of what the relative prevalence of such
browsers is, so they know how important it may be for any given
feature, is a bit onerous. It is also the case that writing
conditional documents can result in complex and not extremely
readable source documents. If you have the proper tools, then
this problem could be dealt with automatically by the document
editor (program). On the other hand, if it can be dealt with
automatically, then we might as well put those tools over on
the server side where it can be done at a level appropriate for
the particular site.
Note that I'm talking with two faces here. Earlier today I was
arguing for giving designers more control over the format. Now
I'm arguing that less control is preferable. I guess I'm not
saying that they *shouldn't* be able to provide conditional
code, in fact there are times when I would definitely like the
functionality. However I don't believe that it should be
required.
P.S. One of my previous messages apparently crashed many Mime
user agents around the world. I have a strong suspicion that
this list server is improperly removing the last line of my
headers (namely the boundary line).
From: Kee Hinckley <nazgul>
Date: Tue, 18 Oct 94 22:50:12 -0400
Message-ID: <941018225012.6448@utopia>
Status: R
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Intermail Mail Boundary #1=_"
Is there a list admin in the house?