Re: [css4-mediaqueries] Bandwidth Media Queries

I agree. Such media queries should either stay the same all the time or should not be used. Otherwhise, in such case :

    html { background: black; }

    @media (min-bandwidth: 0.5) { html { background-image: url(smallImage.jpg); } }
    @media (min-bandwidth: 2) { html { background-image: url(bigImage.jpg); } }
    @media (min-bandwidth: 4) { html { background-image: url(veryBigImage.jpg); } }

If the person who see the website use a mobile connection which degrades over time (because that person is moving away from antennas), it’s possible that all the three images got dowloaded and, at the end, none of them is displayed.

The solution to that kind of problem is to extend the “image()” fallback to include the same kind of resource negotiation as the HTML WG want to add for <picture>.

    @picture myPicture {
        witdth: [assign a new intrinsic width for the picture]; 
        height: [assign a new intrinsic height for the picture];
        /* auto (by default) takes the intrinsic size of background image */
    
        background-color: black;
        background-size: 100%;
        background-image: image(
            @media (min-bandwidth:4)       url(veryBigImage.jpg),
            @media (min-bandwidth:2)       url(bigImage.jpg),
            @media (min-bandwidth:0.5)    url(smallImage.jpg),
            none
        );
        
    }
    
    html { background: picture(myPicture); }

The decision to choose one “image” item over another happens at the time where the image is downloaded, and should probably not be changed after that (even if this is left at browser’ discretion). Anyway, the image will be consistent on the site if she’s used more than one time.

Also, users could decide to “cap” their returned bandwidth in order to save connection usage (for example if they pay per-mega).

Regards,
François

From: Stefan Wallin 
Sent: Saturday, March 31, 2012 10:08 AM
To: Lea Verou 
Cc: Brad Kemper ; www-style list 
Subject: 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 09:52:41 UTC