W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

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

From: Matthew Wilcox <mail@matthewwilcox.com>
Date: Tue, 7 Feb 2012 21:24:45 +0000
Message-ID: <CAMCRKiLJMxO2wxP1myA8ahppbciAdnKzUTpdzHH77q5nS=y3kg@mail.gmail.com>
Yes, you're getting the point I'm trying to make :D

However, there most certainly IS a use case for screen size. The
designers would kill me if I served up images that had to be
up-sampled to fit the device width. And I'd kill them if I had to send
an image 6 times larger than needed just to cater for a possibliity
that the browser may end up six times larger than it is now.

It's not purely about information adaption, there is visual design
consideration that is as paramount as any other argument. If a website
looks janky, the client (as in the web development agency's client)
isn't going to pay for it.



On 7 February 2012 21:19, Charles Pritchard <chuck at jumis.com> wrote:
> On 2/7/2012 1:14 PM, Matthew Wilcox wrote:
>>>
>>> > ?Also, I am writing this on a laptop via a throttled mobile connection.
>>
>> It'd be nice if sites had the capability to adapt to that throttle
>> then wouldn't it...
>
>
> As I read through this thread -- all of these use cases are about bandwidth.
>
> a) Images are too big.
> b) Too many javascript files.
> c) Too much html content.
>
> The proposed fix:
> a) Send a display size header, have the server do magick.
>
> That doesn't seem to be the right approach.
>
> Let me know if I've got that right / wrong.
>
> I'm fine with sending a bandwidth-request header.
> Something to say: hey you, I'm on a metered connection, don't waste my time.
> Or just, hey, this connection is slow, give me a hand here.
>
> That one directly addresses the issue.
>
> On the server-side, I can decide if I want to serve downsampled images,
> lesser content
> or otherwise repackage my javascript.
>
> Nothing to do with viewport sizes.
>
> -Charles
>
>
Received on Tuesday, 7 February 2012 13:24:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC