- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Tue, 7 Feb 2012 09:55:02 +0000
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 client). -Jason 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