Thanks for responding, Boris! > One issue with this is that in many cases the UA may not yet know what > media queries apply to the document when starting the sheet loads. In > some cases it does, of course, but those may be rarer than you think…
That makes sense. For my own understanding, do you have any examples of media queries that can't be determined until a later time? In observing trends in web development and in my own work, it seems to me that the following types of queries are most commonly used to deliver cross-device Responsive designs: min-width max-width min-device-width max-device-width min-device-pixel-ratio I'd presume a UA would be able to run these before a page has begun loading, or at least after a meta[name=viewport] element has loaded (so that would need to come before stylesheets in the head to take advantage of this feature). Is that not the case? I'm not entirely sure I understand your iframe example and how it would relate to the media query differently than any viewport width. I'd love a clarification on that part, but the following part is clear to me: > There are also various user actions that can similarly change the width of > even the toplevel window in CSS pixels such that it's larger than the nominal > device width in CSS px (e.g. zooming out, in UAs that change the size of CSS > px when you zoom). Okay. But even if a user's preferences have previously changed the default font-size of the browser (say, by increasing their font size), wouldn't the UA would be privy to that size at load time, and be able to use that in determining whether, say, an EM-based media query was applicable to the viewport width or not? > Except device queries and viewport queries are not at all the same thing, of > course. Conflating the two may be ok for a library that developers are free > to not use if it's making assumptions that are not true in their use cases, > but it's really not OK for a UA to do. Understood. This example would be difficult to apply broadly, which is unfortunate as it'd be the area where the actual savings in HTTP requests could be made. That said, merely deferring the load of stylesheets that don't apply at initial load would be a huge performance improvement for users. In a few large-scale responsive designs I've reviewed, sometimes more than half of the CSS delivered in the head of a page does not apply at all in small-screen contexts, yet the device must wait while all of it loads. >> 2. Reducing the amount of time that an unresponsive stylesheet can >> block page rendering > > Yes, indeed. Excellent. I'd suggest something in the 6-8 seconds range would be reasonable (and that's the timeout implemented in my sample framework above), but that may be too aggressive for most folks' tastes. Thanks again! Scott
