W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

From: Kornel Lesiński <kornel@geekhood.net>
Date: Sun, 05 Feb 2012 01:46:40 -0000
Message-ID: <op.v86m72h6te2ec8@aimac.local>
On Sat, 04 Feb 2012 19:28:17 -0000, irakli <irakli at gmail.com> wrote:

> The most optimal way to handle responsive images and optimize CSS/JS  
> would be on the server-side. However, server-side does not have enough
> information about device capabilities, resulting in emergence of all  
> kinds of cruft-y solutions (e.g. using <div>'s for <img> tags etc.) that  
> should
> not exist.

There are many factors that influence selection of images, and some of  
them (like zoom, available memory, screen/print media) can change after  
images are downloaded. Some factors don't depend on hardware capabilities,  
e.g. user may be roaming or exceeded bandwith allowance and thus strongly  
prefer small images even on high-end hardware.

Instead of sending a lot of information to the server, I think it would be  
better if websites declared what kinds of images are available and let  
browsers choose.

I think it's more likely that the few browser vendors will get client-side  
image selection right, than majority of websites will add good server-side  
logic that takes into account all factors. Look how hard it is for sites  
to get authenticated file downloads right ? most of them use grotesque  
scripts that completely break all caching, resuming, MIME types and often  
mangle filenames. I'd be surprised if image selection scripts were any  
better. Even with a good script, it may be hard to get negotiated images  
properly served/cached via CDNs and proxies. Last time I checked presence  
of Vary header made responses non-cacheable in all major browsers, and  
that can be worse then serving wrong size.

If servers won't take into account all factors properly, then browsers  
will start lying in information they send to the server to force desired  
behavior, and capabilities header will degenerate like the User-Agent did.  
I can imagine all browsers reporting 320px to get 160dpi images, 960px to  
get 300dpi, and 1920px to get 100dpi, regardless of actual screen size.  
That starts happening with <meta viewport> and screen.width already.


OTOH giving browsers ability to select image by DPI/file size at any time  
opens up interesting possibilities, e.g. browser could load low-DPI  
versions of images necessary for initial layout of the page to show the  
complete page sooner (especially that mobile browsers show page zoomed out  
initially), and then replace images with high-DPI versions if  
bandwith/memory/user preference allows that or when user zooms in selected  
portion of the page.

On a page with lots of large images (a gallery or photoblog) browser may  
be forced to load low-DPI versions of images, even if it had enough memory  
to display each image _individually_ in high DPI, so the decision cannot  
even be made purely on per-request basis.

Given all the complexity involved, and potential for innovation in the  
browsers, I'd rather see a declarative solution in the markup (and not  
necessarily via a CSS media query, as this still keeps responsibility with  
developers, not browsers).

-- 
regards, Kornel Lesi?ski
Received on Saturday, 4 February 2012 17:46:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC