Re: Microsoft IE -- it just gets better and better

M. Hedlund writes:
 > 
 > On Sat, 27 Jan 1996, Larry Masinter wrote:
 > > As far as I can tell, the HTTP working group and its
 > > content-negotiation subgroup doesn't have a solution to the problem of
 > > how to do the full complement of feature-set negotiation that is
 > > currently supported by user agent.
 > 
 > I thought we agreed that there is unlikely to be a scaleable HTTP
 > solution;  but that Murray's modular DTD work and conditional HTML might
 > be more fruitful. 
 > 
 > [excellent issue summary omitted.]
 > 
 > > Could most of this be handled with media type registration? E.g., if
 > > Netscape were to accept: text/html and text/netscape-2.0-html, then
 > > Microsoft's browser could express its willingness to accept either or
 > > both. Is this a workable solution?
 > 
 > No, because text/netscape-2.0-html encompasses many features, and MSIE 
 > may only support some of these (which is true).  Therefore, MS could not 
 > incrementally implement features encompassed by that media type and 
 > sufficiently communicate that incremental ability.
 > 
 > Marc Hedlund <hedlund@best.com>, <marc@organic.com>
 > 

Short of a global, clonable, database of browser features & bugs, indexed by
USER_AGENT string, (which won't work if people like Microsoft continue to
make up fake USER_AGENT strings ... and this is where I have a problem
with what they're doing), how could a content-negotiation
solution work?  

The problem with accept headers is simply that there'd have to be so
damn many of them to represent the space of individual browser
features (and bugs!).  And besides, no browser maker is going to put
an accept ( or "reject"? ) header in their requests representing a bug
in that browser.

The only way that accept headers would be even marginally usable for
this purpose is to define groups of features that are usually found
together, so that it would be possible to describe a browser's
capabilities with just a few headers.  Otherwise it is simply too
unwieldy. Even doing it this way is probably still too unwieldy. To
make this approach work, it would also necessary to have a "reject" or
"do-not-accept" header as well, so that a browser could say "I'll take
whatever you'd give Netscape 2.0, _except_ I don't indent on blockquote
and I don't have frames".

My conclusion:  trying to implement browser feature descriptions
based on accept headers is barking up the wrong tree.

The mindset people seem to be stuck in is that you need to have static
html pages, one for each possible html feature combination.  This is
subject to combinatorial explosion, and therefore is not a viable
solution.  There are many approaches to this problem that do not
require such a LAME(tm) approach.  To name a couple: programmatically
generate pages in a way that takes the browser features into account,
or write pages in a meta-language that can be macro-expanded at the
time it is displayed based on browser capabilities, and (optionally)
cache the ones that are commonly requested.

--Shel Kaphan
  sjk@amazon.com

Received on Saturday, 27 January 1996 17:27:16 UTC