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

[whatwg] Use of media queries to limit bandwidth/data transfer

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 31 Jan 2012 22:42:18 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1201312238560.3868@ps20323.dreamhostps.com>
On Thu, 8 Dec 2011, Ashley Sheridan wrote:
>
> I couldn't find anything about this specifically, and I'm not sure if 
> this is the best place to ask this, but here we go.
> 
> I've been trying to optimise my site (as a test case) for mobile usage 
> and one area where I found issues was with the media queries used to 
> link CSS files. I noticed that despite each <link> tag including the 
> maximum and minimum screen widths (which is about the minimum that is 
> supported across every majority browser) the browsers (IE, Opera, 
> Firefox, Chrome) all seemed to download every CSS file. These days, when 
> it's recommended to use sprites to reduce bandwidth on multiple images, 
> it seems crazy that there's no contingency to reduce bandwidth on CSS 
> files that the browser should know it doesn't need. Is there a 
> particular reason for this? I can understand for devices like a tablet 
> where the orientation is expected to change often and it might want to 
> download multiple CSS files to reduce the latency that downloading as 
> required would bring, but that doesn't explain why a desktop browser 
> would still need to grab CSS that is clearly labelled as being for a 
> maximum screen width of 300px.
> 
> From a usage point of view, I wouldn't be too unhappy at having my 
> browser download extra CSS found in a media queried <link> if I decide 
> to resize my browser, as that is not what I'd call typical browsing 
> behavior, but I would expect a tablet or mobile to be more responsive as 
> they are types of devices that are prone to be moved around and tilted.

On Thu, 8 Dec 2011, Tab Atkins Jr. wrote:
> 
> The reason for this is so that, if the document width later changes such 
> that one of the excluded stylesheets is now valid, we don't want to have 
> a noticeable delay while we fire off a network request and retrieve the 
> new stylesheet.  Remember that widths refer to the browser window, not 
> the monitor, so small widths *can* (and do) occur on desktop browsers.
> 
> This delay is potentially bad for usability, but more importantly, it's 
> bad for scripts, as there's a substantial window in which a <link>'s 
> media query resolves to true, but it either doesn't have an associated 
> Stylesheet object, or the Stylesheet is a "dummy" that doesn't yet 
> contain the real values.  Stylesheet access is synchronous, so we'd have 
> to block the entire JS thread while waiting for it to come in.

On Thu, 8 Dec 2011, Boris Zbarsky wrote:
> 
> There are several separate problems here.  Below I focus on the Gecko 
> perspective, which is what I'm familiar with.
> 
> First of all, the code was written originally before mobile started 
> being a concern.  And in the desktop space, there are very few media 
> queries which are guaranteed to never match.  For example, the size of 
> the CSS viewport is not fixed on desktop.  Furthermore, until the recent 
> media query implementation all that you could filter on was the actual 
> medium, and in the common cases you wanted to download both the print 
> and screen sheets and other media were unused.  So there wasn't much 
> need to optimize away stylesheets whose media queries did not match.
> 
> Second, there is a slight problem of spec collision.  While sheets whose 
> media queries do not match should not affect rendering, there are no 
> provisions for not exposing their object model, which of course requires 
> downloading the stylesheet.  I agree it might be good to add such 
> provisions, because there are some media queries we really _do_ know 
> statically will never match in Gecko.  They're just a much smaller set 
> than most people think.  And of course there may be page compat 
> concerns.
> 
> [...]
> 
> Screen widths in media queries are in CSS pixels, not in device pixels.
> 
> There are operating system settings, that can even be changed 
> dynamically, that change the screen width in CSS pixels.  There are even 
> browser settings that change the screen width in CSS pixels.  Try this 
> in Firefox:
> 
>   <input type="button" onclick="alert(window.screen.width)"
>          value="click me">
> 
> Load that page, click the button, zoom in as much as you can using the 
> browser's zoom function, and click the button again.  Over here, the two 
> alerts show 1920 and 640 respectively.

I haven't changed the HTML specification in response to the above. It 
isn't clear to me what we should do, if anything.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 31 January 2012 14:42:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC