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

[Boris Zbarsky]

On 2/6/12 11:27 AM, Matthew Wilcox wrote:
> I disagree. Screen size is at times *exactly* what is needed, as it *is*
> constant throughout the experience.

No.  It's just not, for at least two reasons:

1)  Screen sizes are reported to the page in CSS pixels, and the number 
of CSS pixels per device pixel is not an invariant (e.g. it changes on 
zoom in some browsers).

2)  Devices (including laptops) can be docked and otherwise have 
external screens connected to them.

Point 1 above means that the user zooming your page will change the 
"screen size" as perceived by the page.

> *Viewport* size is what we shouldn't be using

Viewport size has the additional constraint that viewports can also be 
resized by users.  But you shouldn't be "using" any of these.  Depending 
on what you're "using" it for, of course...  What _are_ you trying to 
use it for?

> The problem with using viewport instead of device size is client-side
> caching. It completely breaks things. As follows:
>
> 1) The user requests the site with a viewport at less than the device
> screen size.
> 2) The user browses around for a bit on a few pages.
> 3) The user maximises their browser.
> 4) All of the images now in the browser cache are too small.
>
> How does the client know to re-request all those pre-cached images,
> without making an arduous manual JS-reliant cache manifest? Or without
> turning off caching entirely?

If we posit that we're putting the viewport size information in an HTTP 
header, a server would simply send the appropriate Vary header in its 
response.  Then the client would know that its cached content is no 
longer valid if the request header it's about to send doesn't match what 
it sent when it received the cached content.  So this is not a problem 
per se.

The problem, again, comes with viewport and screen size changes while a 
page is loaded, not across page navigations.

> The solution is to send an image that is as large as the device will
> ever need

Whatever that means.  How would you even determine this?

> Yes, this isn't ideal, but it solves the problem and it solves it very
> well for small devices whilst maintaining client-side caching. There's
> very little difference in file weight between an image 320px wide and
> one 480px wide, so the overhead of supporting landscape even if you're
> currently only at portrait isn't anywhere near as great as un-negotiated
> content.

Except you get screwed (or more precisely show a crappy grainy image) if 
the user actually zooms in on their device, no?

-Boris