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

On 7 February 2012 00:12, Jason Grigsby <jason at cloudfour.com> wrote:

> I agree that this is a problem. I?ve spent far too much time trying to
> find solutions for images in responsive designs and none that I reviewed
> work. (research at http://cloudfour.com/responsive-imgs-part-2).

Seconded, my work has been http://adaptive-images.com

> But I find the arguments that Henri Sivonen made against putting the
> information in the header to be compelling:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034642.html

> FWIW, there was an RFC back in 1996 describing a similar request:
> http://tools.ietf.org/html/draft-mutz-http-attributes-01
> Personally, I?d rather see a new element or a new image format a la the
> "add html-attribute for 'responsive images'" thread going on right now. Or
> if it is headers, I?d like to see something that is more inclusive and
> could be used for servers requesting different information instead of
> codifying something only for screen size.

Absolutely agree that we should not be concentrating on one specific thing.
What I want is the ability to have the server ask for whatever info it
needs about the client device/environment, and have that sent as a header.
And only sent if the server has asked. I don't mean we want "screen size"
alone, that is but one example of something the server might care about.
Bandwidth is another, as is viewport size, and I am sure there are a lot
more. I want to see a *communication method* defined here, not a one-issue
semi-solution to an overly specific example of what is in reality a much
broader problem (the server not having reliable information about the


Also, as I've mentioned whenever I talk about this stuff: server side is
ONE half of the solution. The other is new HTML. They do two different
things, and they appear superficially similar when they aren't. Server side
adaptation is about the times when it's right for the server to take
automated action based on the client's capabilties: e.g., sending lower
quality graphics when it detects the bandwidth is low. Mark-up solution is
about sending actual different URLs. e.g., an about page mug-shot. At high
device sizes this may be a full-length body shot. At smaller sizes it's not
practical to simly shrink it as you no longer recognise what's important,
so you substitute a head and shoulders shot for lower screen sizes.
Different content that's doing the same semantic job.

Received on Tuesday, 7 February 2012 01:55:02 UTC