W3C home > Mailing lists > Public > www-talk@w3.org > January to February 1996

Re: Conditional HTML w/<INSERT> (was: Microsoft IE)

From: David Ornstein <davido@apocalypse.org>
Date: Mon, 29 Jan 1996 11:53:33 -0800
Message-Id: <2.2.32.19960129195333.0067f6e8@objarts.com>
To: "M. Hedlund" <hedlund@best.com>, John Franks <john@math.nwu.edu>
Cc: 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
Received on Monday, 29 January 1996 14:53:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT