Re: [css-fonts] font prefetch hints

On Thu, Oct 30, 2014 at 9:58 AM, Zack Weinberg <zackw@panix.com> wrote:
> This is related to, but abstractly independent of, the font-timeout
> behavior proposal being discussed in another thread.  I like that
> proposal, but I think there's an additional, independent high-level
> knob that could be very useful to authors.
>
> Right now, @font-face { ... } often doesn't trigger an immediate
> fetch, because browsers are optimizing for minimal network traffic, on
> the assumption that they're not going to need any particular font
> until layout tells them otherwise.  In the increasingly common case
> where sites want to specify exact fonts for everything, this is the
> wrong move; browsers ought to kick off loads immediately upon
> encountering the @font-face.
>
> On the other hand, sometimes a site might want to specify a whole
> bunch of @font-face rules in a site-wide CSS file, that may or may not
> be relevant on any given page; the example that comes to mind is
> Wikipedia, on which any given page *might* include a few words in some
> script other than that used for the primary language, and they'd like
> not to have to worry about whether the reader's OS shipped fonts for
> that script.
>
> This is orthogonal to the 'font-rendering: optional/swap/mandatory'
> mechanism because a font might be mandatory *if used on a particular
> page*, but unnecessary to download until it's known to be needed --
> math and icon fonts, or those alternate-script fonts (for which one
> would probably use local() to further hint that system fonts will do
> if available).  Conversely, a font used for body copy on every page,
> but chosen for design reasons, would probably be 'optional' or 'swap'
> but the author would like to tell the browser that it really should
> start loading it now because it WILL be used.
>
> I can imagine heuristics that would do a reasonably good job of
> inferring whether a load should start immediately from things like
> presence or absence of 'unicode-range', whether the font is being
> applied to high-level structuring elements (<body>, <main>, etc), and
> like that, but they are probably too heavyweight to apply for
> prefetching.  It might even be nice to be able to hoist font-prefetch
> hints out of the style sheet into <link> tags, so those loads can
> proceed concurrently with the load of the style itself!  (N.B. FF
> doesn't parse style incrementally and it would be a major overhaul to
> change that.)
>
> Concrete suggestion: in @font-face,
>
>     prefetch: auto | true | false
>
> 'auto', the default, means whatever happens now; 'true' means browsers
> SHOULD load this font immediately

Chrome has been internally talking about something similar for more
than just @font-face resources.  This definitely sounds like something
that can generalize easily.

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

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

The idea is that you match the selectors in @will-use against the
selectors in the document's stylesheets (exact match,
post-parsing/normalizing selectors), and assume that all resources in
the associated rules will be used, and should be preloaded: images,
font faces, etc.

This idea has some problems (I'm not a big fan of selector matching in
this way), but something in this direction seems pretty reasonable, I
think.

>  and 'false' means they SHOULD NOT.

Is this necessary?  The default is already "should not", and I don't
think anyone wants to change that.  We probably just need two values,
for "preload" or "don't", with the latter being the default.

Also, note that CSS doesn't do boolean values; we always end up adding
more than two options at some point anyway, so we just assume that
will happen in the future and name the values after their effects
instead.  Maybe "load-policy: preload | when-used"?

> (Can we stop adding redundant 'font-' prefixes to @font-face
> descriptors where not necessary for parallel structure with font-*
> properties in style rules, please?)

Unfortunately, we can't stop now; the inconsistency would be worse
than the continued verbosity.

~TJ

Received on Thursday, 30 October 2014 18:29:52 UTC