[9716] in www-talk@info.cern.ch
Conditional HTML w/ (was: Microsoft IE)
daemon@ATHENA.MIT.EDU (M. Hedlund)
Mon Jan 29 13:27:26 1996
Date: Mon, 29 Jan 1996 10:12:17 -0800 (PST)
From: "M. Hedlund" <hedlund@best.com>
To: John Franks <john@math.nwu.edu>
Cc: www-talk@w3.org
In-Reply-To: <199601291712.LAA28297@hopf.math.nwu.edu>
Resent-From: www-talk@w3.org
On Mon, 29 Jan 1996, John Franks wrote:
> One suggestion has been a conditional HTML which is parsed and interpreted
> by the client. This seems to be a very good idea. It completely solves
> the caching problem. One drawback is that documents might become
> substantially larger if they contain all virtual versions.
My recent thinking on this issue is that a form of conditional HTML could
be implemented with <INSERT>. Give some <PARAM>'s that describe the
conditions under which the insert SRC should be requested, and let the
browser decide whether it should get the insert or not.
<INSERT SRC="http://www.name.dom/path/table.html"
TYPE="text/conditional-html">
<PARAM NAME="condition" VALUE="vendor-tables/1.1">
<P>Your browser doesn't recognize vendor-tables/1.1, so you're seeing
this instead.</P>
</INSERT>
OR logic could be specified by giving more than one PARAM. AND logic
could be specified by recursive INSERTS. Browsers that don't recognize
<INSERT> get the fallback text.
Advantages:
* Works in keeping with "the SGML heritage of HTML."
* Doesn't stuff all possible variants into one document (avoids filesize
bloat).
* Backwards-compatible.
* Very cache-friendly (not only can primary docs be cached, so can
<INSERT>s).
* Avoids stuffing browser capability description into huge Accept header.
Disadvantages:
* Requires multiple GETs (possibly a good number of them).
* Requires the browser to parse the <INSERT>s before issuing subsequent
GETs. (Maybe we can get around this with <ALIAS>?)
The only thing I can say about the first disadvantage is that HTTP is
moving in a direction that will ease the hit of multiple GETs
(Keep-Alive, HTTP-ng).
Thoughts?
Marc Hedlund <hedlund@best.com>, <marc@organic.com>