W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: Content negotiation

From: Shel Kaphan <sjk@amazon.com>
Date: Wed, 8 Nov 1995 16:06:38 -0800
Message-Id: <199511090006.QAA01982@bert.amazon.com>
To: Brian Behlendorf <brian@organic.com>
Cc: www-talk@w3.org
Brian Behlendorf writes:
 > On Wed, 8 Nov 1995, Shel Kaphan wrote:
 > > And by the way, I wasn't talking about course-grained, dynamic
 > > content-negotiation per se, but about the fine grained and constant
 > > properties of browsers such as "can-center-text",
 > > "tables-can-contain-forms", etc.
 > 
 > Crucial design goal decision time, folks:
 > 
 > Do we want to support, through mechanisms in HTTP, the ability to express 
 > a bitmap of capabilities within specific content types (like HTML), or 
 > not? 
 > 

It's a good question, and the answer, I think, is entirely bound up
with pragmatism.  It seems dubious that the very same group of people
who have managed to create the current divergent subspecies of HTML
and browser behavior will get it together to agree on a standard
mechanism to describe those differences.

As a server application software author, I would much prefer not
to have to grovel around building (and worse, maintaining) my own
database of browser capabilities, so I see it as very useful to be
able to get this information somehow automatically.

On the other hand, it is pretty ugly to have to consider this.
Certainly it has to be tied to a given content type, so we can
maintain the illusion ... uh, I mean perpetuate the present design that
HTML and HTTP are not inextricably linked.


 > Supporting exact capabilities seems to make sense given the current modus 
 > operandi of adding new functionality to the web by incremental advances - 
 > a new feature is desired, a new HTML tag or attribute is defined.  If 
 > this is truely the evolutionary path developers want to see HTML and the 
 > web in general take, then there's not much choice - we have to do it, 
 > elegance be damned.  
 > 

More to the point, does anyone believe that things are going to be
less out-of-control or become somehow less complicated in the future?
I don't.

 > Or, we could decide that HTTP negotiation + simple, solid, 
 > easily-implementable-to-conformance-levels MIME types provide a better 
 > evolutionary path, and avoid the cache-busting swamp of capability 
 > bitmaps.
 > 

I think we should separate content negotiation from the issue of
browser capabilities.  Content-negotiation should be more for
user-preferences, presence or absence of certain helper apps, and
other coarse grained and dynamic decisions that occur at a fairly high
level.  Browser capabilities are (a) certain to be too voluminous to
encode in anything like the Accept header mechanism, and (b) are
constant properties of given browsers (down to the platform and
version).



 > Let's make a decision on this issue, or we'll be passing the buck until 
 > the whole deal is irrelevant.
 > 
 >    Awaiting the day when browsers aren't responsible for rendering, Brian
 > 
 > --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
 > brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/
 > 

It's never too late to procrastinate.  Besides, I've heard it said that
programming is the art of putting off decisions until you no longer
have to make them.    (To the irony-challenged:  I'm joking)

--Shel Kaphan
  sjk@amazon.com
Received on Wednesday, 8 November 1995 19:10:27 GMT

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