Re: Accept- & Content-Resolution headers proposal

On 7 Jun 2007, at 17:06, Travis Snoozy wrote:

>> • Images served with a Content-Resolution header could have their
>> resolution trusted (most web browsers today display one pixel on
>> screen per pixel in the bitmap, and ignore the image's internal
>> resolution parameter, if one exists).
>
> This is of concern to HTML and CSS, the former of which I know  
> properly
> handles this with the "width" and "height" parameters in <img> and
> (IIRC) <object>.

I was referring to images outside of HTML, in that instance (where  
the browser doesn't scale).

> Now CSS may need to grow
> some new features (e.g., the ability to replace the contents of an
> <img> or <object> tag; the ability to @include on DPI; etc.), but that
> would still be very much in the problem-space for that technology.

That's already happening, which is why I didn't refer to it. See  
below for why both are preferable to CSS alone.

> I don't see any benefit to putting this information in the
> transport, except for the fact that you could have the server do the
> work instead of the client. IMHO, the appropriate place for all of  
> this
> _is_ the client -- the client knows the most about its presentation
> environment, and the server shouldn't have to know or care about every
> little detail

The reason for putting it in the transport is to reduce bandwidth  
overhead whilst still giving a crisp presentation.
You could send all screen clients the 288dpi version and print  
clients the 4800dpi version of whatever resource it is, but you'd be  
wasting a lot of bandwidth. Also this is needed for all images, not  
just those referred to by CSS or HTML (HTML has no way other than the  
poorly supported LOWSRC attribute to select on resolution anyway)


- Nicholas.