W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: distinguishing browser types

From: Robert S. Thau <rst@ai.mit.edu>
Date: Fri, 28 Apr 95 10:36:04 EDT
Message-Id: <9504281436.AA08457@volterra>
To: wmperry@spry.com
Cc: www-talk@www10.w3.org
   Date: Thu, 27 Apr 95 22:57 PDT
   From: wmperry@spry.com

     But what about a browser that is ultra-configured, and really _CAN_
   display every type and its grandmother with no lossage whatsoever?

Such a browser would have to figure out how to deal with media types
which were just invented by the guy who runs the server, for which
viewers are not generally available --- to say nothing of the fun to
be had in writing the viewer for application/binary.  Whoever figures
out who to do all *that* can surely figure out how to get his browser
to put an explicit "q=1.0" on the "Accept: */*" header, to suppress
the inappropriate default ;-).

More to the point --- maybe I'm thick, but but I really don't see how
a browser which deals "properly" with *any* media type could possibly
exist, since people can invent new ones at will, so I don't feel
obliged to cater to it (especially when every other browser out there
would be served better by something else).

   Servers
   should make assumptions like this, no matter if they are justified at the
   moment.  Browser authors should get off their !#%!#@ and do it right.

Agreed --- if we can agree that "doing it right" means specifiying
explicit quality values on Accept: headers.

However, so long as the browsers *don't* provide quality values, the
servers have to make assumptions, whether justified or not, and the
only choice we have in the matter is trying to find the set of
assumptions which will cause the least trouble.  My personal view is
that defaulting quality on everything, including */*, to the same
value, isn't the right choice.

rst
Received on Friday, 28 April 1995 10:36:17 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC