[9725] in www-talk@info.cern.ch
Re: Conditional HTML w/ (was: Microsoft IE)
daemon@ATHENA.MIT.EDU (David Ornstein)
Mon Jan 29 15:10:45 1996
Date: Mon, 29 Jan 1996 11:53:33 -0800
To: "M. Hedlund" <hedlund@best.com>, John Franks <john@math.nwu.edu>
From: David Ornstein <davido@apocalypse.org>
Cc: www-talk@w3.org
Resent-From: www-talk@w3.org
At 10:12 AM 1/29/96 -0800, M. Hedlund wrote:
>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.
Achieving AND and OR this way might (I can't quite get it clear in my head)
get in the way of clean (proxy-server) caching.
>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).
Good.
>* 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).
Everything is a tradeoff, but I'll point out that this has a
performance-related predisposition towards browsers that don't understart
the new construct. Because the fall-back form
(<P>Your browser doesn't recognize vendor-tables/1.1, so you're seeing
this instead.</P> in the example above) is always sent, browsers that *do*
understand the new construct will be, in a sense, penalized by being forced
to do the extra GET (and having to have spent extra transport time getting
the unneeded fall-back).
Of course, this would be the way to maintain backward compatibility, but...
-----------------------------------------------------
David Ornstein
Outbreak: http://objarts.com/outbreak-unreg
BrowserCaps: http://objarts.com/bc
Personal Info: http://objarts.com/davido
