[whatwg] RWD Heaven: if browsers reported device capabilities in a request header
bzbarsky at MIT.EDU
Mon Feb 6 08:58:55 PST 2012
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
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
Except you get screwed (or more precisely show a crappy grainy image) if
the user actually zooms in on their device, no?
More information about the whatwg