W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Media Queries and optimizing what data gets transferred

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 30 Jan 2013 09:46:21 +0200
Message-ID: <CAJQvAufs9676owRj_f400joNmFGcZKkvrOKZh6KQgMxaFFENVw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Andy Davies <dajdavies@gmail.com>, www-style list <www-style@w3.org>, Ilya Grigorik <ilya@igvita.com>
On Mon, Jan 28, 2013 at 6:06 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 5:40 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On Fri, Jan 25, 2013 at 8:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> As Boris has explained, it's not performance issues, but rather author
>>> expectations.  The average author expects a CSSOM to exist for all the
>>> stylesheets in the page, and when the set of matched MQs changes, for
>>> the styles to change at the same time, not a network-roundtrip later.
>>
>> Does the average author really expect anything about CSSOM? I would
>> guess that the average author doesn't use CSSOM beyond the sugaring
>> for the style attribute and maybe getComputedStyle() and even those
>> hidden behind a JavaScript library.
>>
>> The use cases for fiddling with the style rules of external sheets in
>> the OM (beyond the immediate style attribute sugaring) don't seem that
>> common.
>
> Enough do that you get compat bugs if you break the assumption,
> apparently.  I suspect Boris can provide more detail if you desire.

"Enough to get compat bugs" is quite different from "average author
expects". The conclusion might be the same, sure.

> So, proposal as it stands is:
>
> Add an "async" (or "defer", whatever is closest to the semantics we're
> trying to achieve) to <link>.  I guess currently only rel=stylesheet
> pays attention to it, but other rels can opt-in as well on their own.
> (Add it to <style> as well, with the semantics applying to @import'd
> sheets? Maybe confusing, since you wouldnt' want to automatically
> opt-in the @import rules in a <link async> to be async as well.
> Perhaps we can add this to the @import grammar instead.)
>
> An async stylesheet never blocks the parsing or JS thread, or any
> other loads started during page load (or just from the parser?). When
> the network queue is empty, the browser begins requesting async
> stylesheets.  (Replace this with appropriately technical language
> cripped from <script>'s loading algo, if that would help.)
>
> A browser MAY defer indefinitely the loading of an async stylesheet
> whose media query is false.
>
> An async stylesheet does not expose a CSSOM at any time, whether it's
> loaded or not, until the author requests it.  This includes showing up
> in the document.styleSheets list, etc.  The author can request the
> CSSOM be exposed by calling LinkElement#requestCSSOM(callback?) (name
> pending).  If the stylesheet is not yet loaded, it puts a load on the
> event queue.  It then puts an action on the event queue to expose the
> CSSOM, and if the optional callback was provided, call the callback,
> passing it the CSSStyleSheet object thus generated.
>
> If this sounds good, I'll put it on the wiki.  We can discuss it
> internally, then I'll send it to WHATWG for further review and request
> for addition.

Sounds good to me if you change "A browser MAY defer indefinitely the
loading of an async stylesheet whose media query is false." to "A
browser MUST defer the loading of an async stylesheet until media
query is true."

Otherwise, you fail to make a promise, and if you don't promise,
authors who want a promise will still seek solutions where they can
control in their JS or server-side code what decisions are made.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 30 January 2013 07:46:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT