[whatwg] Use of media queries to limit bandwidth/data transfer
Ian Hickson
ian at hixie.ch
Tue Jan 31 14:42:18 PST 2012
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list