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

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

From: M. Hedlund <hedlund@best.com>
Date: Mon, 29 Jan 1996 12:21:15 -0800 (PST)
To: David Ornstein <davido@apocalypse.org>
Cc: www-talk@w3.org
Message-Id: <Pine.SGI.3.91.960129121402.22741C-100000@shellx.best.com>

On Mon, 29 Jan 1996, David Ornstein wrote:

> At 10:12 AM 1/29/96 -0800, M. Hedlund wrote:
> >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.

I don't think so.....the browser is just sending out a GET.  The logic 
which caused it to make that GET is irrelevant to the cache controller.

> 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.  

Yes, that's true, but browsers that recognize conditional INSERTs are 
also much more likely to be able to request Keep-Alive connections.  In 
other words, browsers that can make conditional GETs get probably also 
avoid the start-up and tear-down times associated with them.

> 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). 

The fall-back is short.  It seems a small price to pay.  ;)

Marc Hedlund <hedlund@best.com>, <marc@organic.com>
Received on Monday, 29 January 1996 15:25:02 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:19 UTC