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

Re: distinguishing browser types

From: Brian Behlendorf <brian@organic.com>
Date: Thu, 27 Apr 1995 14:09:11 -0700 (PDT)
To: Marc VanHeyningen <marcvh@spry.com>
Cc: www-talk@www10.w3.org
Message-Id: <Pine.3.89.9504271354.X10331-0100000@eat.organic.com>
On Thu, 27 Apr 1995, Marc VanHeyningen wrote:
> > Why shouldn't the mime-type fields in the mailcap entries look exactly 
> > like the Accept: headers (i.e., why "quality" instead of "q"?).  
> 
> Well, because "quality" seems to fit better with the other parameters already
> in mailcap files (things like "compose", "test", "description" and "print")
> while "q" does not mean anything out of context.  What's the advantage
> to "q"?

Ah, okay, I didn't realize that the mailcap spec and the mime-type spec 
where so discontiguous (that was brilliant).  

...
> > "well I'd really prefer mpeg over quicktime" so it'd set mpeg to 1.0 and 
> > quicktime to 0.9, avi to 0.8, etc...  this really could be quite a 
> > powerful mechanism.
> 
> Things brings up the interesting split: the q parameter is intended to
> express lossiness of presentation, not user preferences.  Overloading it
> has some interesting implications (e.g. most people might prefer to use
> JPEG over GIF, but really it depends on how the image originated, since
> converting a GIF to a JPEG for transmission will make it worse, not better.)

According to 
<URL:http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/HTTP1.0-ID_38.html#HEADING112>:

q
     The quality factor chosen by the user agent (and configurable by the 
     user) that represents the desirability of that media type. In this 
     case, desirability is usually a measure of the clients ability to 
     faithfully represent the contents of that media type to the user. 
     The value is in the range [0,1], where the default value is 1. 

How does the browser determine "the clients ability to faithfully represent
the contents of that media type to the user"?  The best the client could do
would be 0 or 1.  I might have a much better WAV player than MPEG player, but
I'd much prefer to get MPEG streams given that I know they pack higher
quality per byte.  At some level, the user should have control over this. 

In a general sense, overall "quality" shouldn't be mapped directly to 
media types, I agree.  The only thing that really maps to quality is 
bandwidth in most cases - so an overall "Accept-Quality" header might be 
needed (implemented as a slider replacing the throbbing N at the top of 
my browser :) that the server uses to determine what to send.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/
Received on Thursday, 27 April 1995 17:09:13 UTC

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