Re: Accept- & Content-Resolution headers proposal

On Thu, 7 Jun 2007 17:20:02 +0100, Nicholas Shanks
<contact@nickshanks.com> wrote:

<snip>
> 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. :)

> 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.

This confused me at first, but then I realized you were talking about
CSS media types. I'm betting that CSS doesn't have anything to switch on
DPI yet. As a totally fictional example:

@media screen.300dpi {
@import url('/300dpi.css');
}

@media print.1200dpi {
@import url('/1200dpi.css');
}

Syntax, of course, would be up to negotiation, but this provides a
general idea. The DPI switching should be done in CSS.

> 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)

(I've never, ever heard of "LOWSRC"; is it even part of HTML? In any
case, presentational differences should be handled in CSS, not HTML
directly.)

Yes, but the respective clients should be responsible for coming up
with a way to determine which resource to choose. HTTP is, after all,
the _HyperText_ Transport Protocol first and foremost -- it absolutely
supports transferring any and all other file formats, but "dpi" doesn't
make sense in the context of retrieving an HTML file*. It also is
not universal; it would be nonsense for an ISO image, or a vector
graphics file, or an MP3, etc., etc. If it's not good for HTML
specifically, and it's not good for all files generically, why does it
belong in the transport?

For example -- you can vary on language. Language is clearly important
to all the contents of the HTML file, and is generally applicable (to
some degree) to all files. Media type is, again, generally applicable
to all types -- given an abstract thing, you can oftentimes represent
the same idea with different concrete instances. 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?

-- 
Travis

* Given that the primary role of HTML is to encode structure and
semantics, not presentation. I argue that DPI selection is a quality of
presentation.

Received on Thursday, 7 June 2007 17:04:52 UTC