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

Re: Media Queries and optimizing what data gets transferred

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 28 Jan 2013 08:06:44 -0800
Message-ID: <CAAWBYDAAj-ct-n7KgUhTO6a8_OEvVw1V3B=vaQq8jbaii6Bx5g@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Andy Davies <dajdavies@gmail.com>, www-style list <www-style@w3.org>, Ilya Grigorik <ilya@igvita.com>
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.

> To me, optimizing the availability of inapplicable style sheet data in
> the OM over what gets transferred seems totally backwards compared to
> what the mythical average author wants.

Optimizing for the worst rather than the average is distressingly
necessary in the web. :/

>> If any browser *did* defer them indefinitely by default, they'd get
>> compat bugs.
> This I can believe.
> So could the problem be solved by adding an attribute on <link> that
> turns off the ability to reach the OM of that stylesheet from scripts
> (at least unless some async access request API is used first) and then
> making browsers not load stylesheets until they are applicable (i.e.
> making e.g. printing wait for additional stylesheets to be fetched)?

I like the idea of making the OM completely inaccessible until you
explicitly request it, rather than having scripts commonly race
against the network request and break when they win.

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.

Received on Monday, 28 January 2013 16:07:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:25 UTC