kenjibaheux/css-override-lazy-loading

A proposal for CSS to let web developers override CSS's lazy loading behavior.

Overriding the lazy loading behavior of assets

A proposal for CSS to let web developers override CSS's lazy loading behavior.

#Background# By design, in CSS, assets like fonts are lazy-loaded.

This is a sane default behavior, as it allows web developers to re-use the same CSS file containing all the required definitions accross all pages in a given website without having to worry about superfluous downloads of assets. It also enables the unicode-range behavior in @font-face.

Unfortunately, in the case of fonts, this also contributes to the "blank text" problem: the page appears rendered but the text content is invisible for a while. This is because the font is only downloaded when it has been determined that it’s absolutely needed.

A good web developer should have a good idea of which assets are critical.

For fonts, while the Font Loading API offers a solution to these problems, it requires JavaScript and a non trivial amount of effort from web developers. Also, if you use a third party library for your asset loading needs, it introduces an extra RTT.

#Strawman# Allow web developers to give hints to the user agent about which assets matter.

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'),
  url(http://example.com/opensans/normal400.woff2) format('woff2'),
  url(http://example.com/opensans/normal400.eot) format('eot');
}

.myawesomebg {
 background-image: url('awesome.png');
}

.maintext {
 font-size: 2.5em;
 font-family: 'Open Sans';
 font-weight: 400;
}

@will-use {
  .maintext;
  .myawesomebg;
}

In which case the user agent can infer that actively downloading Open Sans 400 as well as awesome.png should pay off.

#Contributors# With advices/contributions from: Tab Atkins, Ilya Grigorik, David Kuettel.

css-override-lazy-loading's Issues

Implication for unicode range

What if the font-family is defined with several unicode-ranges? the @will-use syntax doesn’t give enough information to determine which subset is a safe bet.

I have a strawman for unicode-range that might help. Will add a link.

Inherent issues with the @will-use proposal

From http://lists.w3.org/Archives/Public/www-style/2014Oct/0518.html

The rough idea right now (which I'm not a huge fan of, but that's
okay) is something like:

@will-use {
.foo;
#bar;
}

I can see where it's nice to have something more general than just for
fonts, but I'm concerned that this still requires you to parse the
entire stylesheet, construct the rule tree, and perform
potentially-nontrivial matches to decide which URLs to preload.
Ideally you would like something that would enable fire-and-forget
speculative loads during parsing.

Which is bad for the targeted use case of kicking requests for resources to be used on the current page as soon as possible.

Extra benefits beyond assets?

Are there other aspects beyond asset downloads that would benefit from @will-use hints?

Long shots: warming up an optional component of the rendering engine (e.g. GPU, complex font rendering engine…)?

What is the meaning of the @will-use contents?

It looks like you're filling @will-use with class selectors, but what does this mean? I think it's supposed to match against selectors for certain rules in the stylesheet, but matching isn't defined. Exact match? Suffix match? Containment? Something else?