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"?
> > 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.
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.)
> Good, but I still think "q" should be used. Isn't this really a MIME
> issue?
Yes, it is; the change would be to the mailcap spec. Mind you, since
most existing browsers that attempt to use mailcaps get it wrong, I'm not
sure how pronounced the effect would be. :-)
- Marc