[9736] in www-talk@info.cern.ch
Re: Conditional HTML w/ (was: Microsoft IE)
daemon@ATHENA.MIT.EDU (M. Hedlund)
Mon Jan 29 18:37:39 1996
Date: Mon, 29 Jan 1996 12:21:15 -0800 (PST)
From: "M. Hedlund" <hedlund@best.com>
To: David Ornstein <davido@apocalypse.org>
Cc: www-talk@w3.org
In-Reply-To: <2.2.32.19960129195333.0067f6e8@objarts.com>
Resent-From: www-talk@w3.org
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>
