Re: Accept- & Content-Resolution headers proposal

On 7 Jun 2007, at 18:04, Travis Snoozy wrote:

>> The reason for putting it in the transport is to reduce bandwidth
>> overhead whilst still giving a crisp presentation.
>
> Well, then, I don't get it. Explain it to me like I'm dumb. :)

I think you do get it.
We all want to avoid scaling up small bitmaps, and provide high res  
art for those who can display it
We all want to reduce bandwidth costs by sending as little data as is  
necessary, whilst maintaining a professional look as above (both for  
the host and the user who pays for/has restricted bandwidth)

> I'm betting that CSS doesn't have anything to switch on
> DPI yet.

not yet but it's coming... some implementations have it already.  
other people have replied to that effect.

> The DPI switching should be done in CSS.

which is great until CSS is not available.  The point of this is to  
provide such switching where it's not already available.
This header would be most important when no CSS is involved (e.g.  
directly accessing a resource outside of HTML/CSS context, or  
selecting a css file in the first place, though this could be done  
with a css switcher file that loads the appropriate sub-resource).

> Content encoding
> applies to all files; it's just a filter. Bandwidth? Q-values! Is  
> there
> a counter-example that's only relevant to a subset of file types?

One of the things i didn't make clear was that this would only apply  
to images and/or files that reference images (and i suppose only  
those that don't have inherent DPI selection for such references,  
e.g. XSL)


Reviewing the feedback so far, it looks like this use case (switching  
DPI) is too narrow to bother changing the spec for as CSS can fill  
95% of the use cases, but that there *is* a need for preferring  
smaller files even if they are of lower quality. I suggest thought be  
focused on that.


- Nicholas.