Re: [css4-mediaqueries] Bandwidth Media Queries

How can people in the business test this?

My mindset on mobile is a bit weird, I've written 3G to represent "fast"
and edge to represent "slow"

I see a untestable real world scenario where the initial request is on 3G
and then every other chunk of parallel requests is on 3G and edge causing a
mixed download of resources which can wildly screw up the layout of the
website.

Example:
So first you download the sources in your shiny picture element marked as
3G or better, then alos your CSS download gets downloaded with 3G and then
your UA detects that the download of that CSS was quite slow and switches
to "edge speed mode"  which then starts to download all  the resources for
slow connections. Now that user has basically downloaded all the resource
you've got which was probably not the intention of the author using these
media queries...

On the other hand if UA's did not respond to these changes mid page
rendering but merely updating the current speed before each download, you
could end up with some images for a fast layout and some for a slow layout
which has the potential of screwing with the authors intentions really bad.



Stefan Wallin
================================
+46 (0) 709-529 036 || stefan.w@festiz.com
http://www.stefan-wallin.se
http://twitter.com/Stefan_Wallin


On Sat, Mar 31, 2012 at 12:38 AM, Lea Verou <leaverou@gmail.com> wrote:

> Oops, yeah, very good point! Even after that, *any* HTTP request it sends
> could be timed, including XHR requests after page load, so that it updates
> its number.
>
>
> Lea Verou (http://lea.verou.me | @LeaVerou)
>
>
> On 30/3/12 09:17, Brad Kemper wrote:
>
>> On Mar 30, 2012, at 2:14 AM, Lea Verou<leaverou@gmail.com>  wrote:
>>
>>  - I doubt UAs or even the OS has access to this sort of information (at
>>> least without running some sort of speedtest).
>>>
>> The UA has to download the HTML file in order to even see what style
>> sheets it includes or links to. So it could time that, and extrapolate the
>> speed from it.
>>
>
>

Received on Saturday, 31 March 2012 08:09:01 UTC