[9742] in www-talk@info.cern.ch
Re: Conditional HTML w/ (was: Microsoft IE)
daemon@ATHENA.MIT.EDU (M. Hedlund)
Mon Jan 29 21:44:11 1996
Date: Mon, 29 Jan 1996 18:28:23 -0800 (PST)
From: "M. Hedlund" <hedlund@best.com>
To: Blake Sobiloff <bsobilof@inet.ed.gov>
Cc: www-talk@w3.org
In-Reply-To: <v02140a09ad32cd0ccd55@[192.239.34.204]>
Resent-From: www-talk@w3.org
On Mon, 29 Jan 1996, Blake Sobiloff wrote:
> >Advantages:
> >* Doesn't stuff all possible variants into one document (avoids filesize
> > bloat).
>
> I've heard a lot of people mention filesize bloat as a (potential) problem,
> but I wonder how much of a problem it really is.
I don't think it would be a problem for the average provider. I'm
assuming, however, increasing complexity in the 'feature matrix' and
increasing effort on the part of Web design houses (such as the one at
which I work) to provide appropriate variations.
> Also, how am I going to test each of the different structures -- keep
> copies of the top five browsers for each platform handy? Yuck!
I don't see how this <INSERT> proposal would be any different than any
other content negotiation system in this respect. Are you arguing
against HTML-feature-negotiation altogether?
> >Disadvantages:
> >* Requires multiple GETs (possibly a good number of them).
> [...]
>
> This seems like a much more significant problem, especially given the
> slow-start nature of TCP connections, plus the additional overhead with
> older server architectures (threads vs. forks).
I'm not denying that, but I am claiming that browsers new enough to
implement <INSERT> will likely also be new enough to implement
Connection: Keep-Alive. Parsing of <INSERT> is completely optional.
I am _not_ arguing that <INSERT> is the best of all possible worlds. The
best of all possible worlds would be published standards and no
extensions -- which could be handled through Internet Media Type
negotiation (that is, through the Accept: header). That scenario is
obviously unrealistic. Therefore, I'm looking for the best solution that
will allow for the following:
* uneven browser feature implementations
* flexibility given rapid feature innovation
* cache-control
* ease of implementation (for browser, server, and html authors)
* backwards compatibility
* avoidance of header bloat
* minimized impact on browser/server performance
Obviously, multiple GETs rate worst on the last point. I would argue
that the other solutions proposed proposed rank a lot lower on many of
the points above.
We all seem to agree that no beautiful solution exists. Can we compare
possible solutions based on their 'score' in the solution space described
above?
Marc Hedlund <hedlund@best.com>, <marc@organic.com>
