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 13:29:41 -0700 (PDT)
To: marcvh@spry.com
Cc: www-talk@www10.w3.org
Message-Id: <Pine.3.89.9504271337.S10331-0100000@eat.organic.com>
On Thu, 27 Apr 1995 marcvh@spry.com wrote:
> Brian said:
> >On Mon, 24 Apr 1995, lilley wrote:
> >> Brian Behlendorf wrote:
> >Alright, I'll concede that - in fact that makes the inline vs. external
> >app question have a very nice answer.  Cool.
> 
> Now, if only browsers would actually do that... instead, we have hacks on
> top of hacks on top of hacks, and nobody dares implement the real spec
> because so many broken clients will cause it to behave in unreasonable
> ways.  Most urgent is to put a quality value that is less than 1 on
> the type */*, unless the client really does mean to say that it can display
> every content-type in the entire world completely losslessly.

I like to think we've gotten close with Apache.... certain presumptions 
were made (an implicit text/html; q=0.5) to account for broken 
(excuse me, all :) browsers.

> >> 3) The quality factor for each listed type should be user-editable via
> >> some sort of dialog box or whatever.
> 
> I've long wanted there to be a quality parameter in mailcap files to allow
> specification of exactly that.  The syntax is pretty simple (just
> "quality=value") and I think somebody would probably be fairly safe in
> implementing it that way.

Why shouldn't the mime-type fields in the mailcap entries look exactly 
like the Accept: headers (i.e., why "quality" instead of "q"?).  

> The quality value is likely an aspect of the viewer used and the hardware
> configuration; I don't think it's something users should have cluttering
> up their preferences screen.

Er, I dunno, my TV at home does a pretty cool job of giving me control over
certain things (contrast, tint, etc) without looking cluttered.  q factors
are something that the user might want to change - I'm really interested in
reading the New York Times (and other publications that offer PDF files as
alternatives to HTML) exactly as it looks on paper, so I'll set my
application/pdf setting to 1.0.  The browser might even be smart 
and group settings by major type and let me set them relatively - i.e.
presents me with a list of all video formats I can see, and I can say 
"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.

> Here's how I suggested phrasing the spec.  Don't remember what ever happened
> to it.
> --
> The "quality" field specifies the degradation factor associated
> with the view-command for this rule.  The value must be a number in
> ANSI-C floating point text representation ranging from 1.0 (no
> degradation) to 0.0 (total degradation.)  This value should be assumed
> to apply to the print command, too, if it exists.  If the quality
> field is absent, a default value of 1.0 may be assumed.  Note that
> this field SHOULD NOT be considered to override the use of the first
> matching mailcap entry.
>  
> This field has the same semantics and syntax as the "q" parameter for
> Accept: headers in HTTP requests {cite the draft for HTTP from the Tim
> BL and the IIIR WG} and is primarily intended for use by WWW clients.
> However, mail readers may use its value for other quality decisions;
> for example, a reader might warn the user not to expect much before
> invoking rules with a very low quality, or check whether the
> sender-arranged ordering of body parts in a multipart/alternative
> entity contradicts quality comparisons.

Good, but I still think "q" should be used.  Isn't this really a MIME 
issue?  

	Brian 

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/
Received on Thursday, 27 April 1995 16:29:41 UTC

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