Re: Accept- & Content-Resolution headers proposal

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

<snip>
> • 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>. If the designer wants an image to be a specific,
pixel-perfect size, he should use this mechanism. If CSS does not have
a similar mechanism, it really should.

<snip> 
> What do people think? I've only spent an hour or so pondering this,  
> so it won't be bulletproof yet.

The browser knows what the user wants to see, and the graphic artist
has a series of layouts. It should be up to the browser and the CSS to
determine what the page layout is going to be. 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.

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 (although the content author might). Taking this idea to
a silly extreme, we could tweak HTTP to send oodles and oodles of
information to the server, and have the server resolve the
whole presentation layer. The server could custom-render a great big
(png|jpg|gif) that gets sent back to the client, along with a linkmap.
Or, the server could render the HTML to ascii, and send that back (in
the case of a text browser). It would be far better, though (again,
IMHO), to let the clients grab a blob from the server, pick over that
blob, and make further fetch decisions based on the contents. That keeps
the server dumb and generic, and the clients can be as dumb or smart as
the authors want to make them -- without requiring any special, extra
support from the server/proxies.


-- 
Travis

Received on Thursday, 7 June 2007 16:06:54 UTC