[whatwg] RWD Heaven: if browsers reported device capabilities in a request header
kornel at geekhood.net
Sat Feb 4 17:46:40 PST 2012
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
> 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
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
More information about the whatwg