Gervase Markham wrote:
> Brendan Eich wrote:
> > > Does anyone object to this course of action? It goes without saying that
> > > this pref would have _no_ user UI.
> >
> > I have no problem with it; I also have no problem with a short default pref
> > that's better than */*. I do not like the image/{png,jpeg,gif} proposal you
> > quote above (what about mng? what about next year's model for which inline
> > image decoders can be field upgraded?). Would it work to do
> > image/gif;q=0.9, image/*;q=1 ?
>
> The current proposal is current because it was the only sensible
> suggestion made in the bug. Now is as good a time as any for other
> suggestions :-) My reading of the RFC suggests image/gif;q=0.9, image/*
> would work.
>
> However, saying that all image types are equally acceptable causes
> forward-compatibility problems - if a new image type arrives that
> Mozilla doesn't support, it will be sent in preference to GIF, which it
> does, and possibly in preference to JPG and PNG because they are all of
> equal precedence.
(Death to GIFs! Let them eat PNGs. :-)
I suppose we could enumerate known image types as you propose (but did you leave
out image/mng, or is that covered by png?), and keep going (it's not as if new
types emerge that frequently). Something about it rubs me the wrong way. More
when I figure out what that is.
> When we gave the W3C feedback on their Common User-Agent Problems paper,
> we did suggest that they suggest a suitable Accept: header for Mozilla,
> given the criteria we are setting. Perhaps we should ask them again?
Sure. I hope it's not too long.
/be
