Re: Media Queries and optimizing what data gets transferred

I may have failed to make myself clear, so I'll try to explain myself
better with code :)

Let's say I have the following styles:
   <!-- High priority CSS. should be loaded before paint for all viewport
sizes -->
   <link href="common_for_all_breakpoints.css" rel="stylesheet"
media="screen">
   <!-- High priority CSSes for the relevant viewport. The one which media
matches is needed as close as possible to first paint. The others can be
deferred, possibly forever -->
   <link href="small_screen.css" rel="stylesheet" media="screen and
(max-width: 599px)">
   <link href="medium_screen.css" rel="stylesheet" media="screen and
(min-width: 600px and max-width: 899px)">
   <link href="large_screen.css" rel="stylesheet" media="screen and
(min-width: 900px)">
   <!-- Low priority CSS. Need to be loaded if JS brings in content that
needs it. -->
   <link href="styles_for_lazy_loaded_content.css" rel="stylesheet">
   <!-- Low priority CSS that can be deferred, possibly forever -->
   <link href="print.css" rel="stylesheet" media="print">

As far as I understand, the `async`
attribute accommodates the "styles_for_lazy_loaded_content.css" use-case.
Using `async` on the viewport specific high priority CSSes will result in
the relevant ones deferred with the irrelevant ones, and will also create a
JS dependency for these CSSes, if we actually need to load them.
I believe there is a place for a different attribute that indicates only
"no JS inspects this CSS, it can be deferred if irrelevant", but without
deferring CSS which media matches and without creating a JS dependency.

Yoav


On Wed, Jan 30, 2013 at 7:16 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Wed, Jan 30, 2013 at 5:59 AM, Yoav Weiss <yoav@yoav.ws> wrote:
> > This sounds like a great proposal that will enable browsers to avoid
> > downloading excessive CSS.
> > What bothers me about it is that if I understand correctly, `async` CSS
> > which `media` matches the current viewport/dpi/etc risks resulting in
> FOUC.
> > What does the `async` attribute mean as far as authors are concerned?
> "No JS
> > inspects this CSS"? "No need to download before first paint"? Both?
> > Something else?
>
> Both.  If you use async on a stylesheet, there is *no* guarantee that
> it will be downloaded by the time the page is first painted, and in
> fact it's likely to not be.  And in my proposal, it's not accessible
> via JS until you explicitly request it to be so.  In general, you
> can't assume it will *ever* be downloaded until you request it in JS.
>
> > IMO, RWD authors often need to define a set of "essential" CSS files,
> from
> > which only one of them applied to the current responsive breakpoint, and
> the
> > others are (at least currently) irrelevant. In this case, only the
> relevant
> > one should be downloaded with high priority and possibly block the first
> > paint to avoid FOUC (as CSS is loaded today), while the irrelevant ones
> can
> > download later/never. I'm not sure this proposal answers that need.
>
> It does.  All the async ones are "low" priority according to your
> categorization, and then you can just run through and request the
> "essential" ones via JS on page load.  It'll still request them
> "slowly", so as to not interfere with the rest of the page, but
> they'll be guaranteed to load in a reasonable amount of time, while
> the rest might not ever.
>
> In other words, normal stylesheets are "high" priority.  Async
> stylesheets are "low".  Async stylesheets that have been explicitly
> requested through the JS API are "medium".
>
> ~TJ
>