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 18:28:23 -0800 (PST)
To: Blake Sobiloff <bsobilof@inet.ed.gov>
Cc: www-talk@w3.org
Message-Id: <Pine.SGI.3.91.960129172837.22741D-100000@shellx.best.com>

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>
Received on Monday, 29 January 1996 21:31:17 GMT

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