Re: [css-fonts] font prefetch hints

On Wed, Nov 12, 2014 at 3:15 AM, John Daggett <jdaggett@mozilla.com> wrote:

>
> Hi Yoav,
>
> > Regarding the opt-in for preloading purposes, I believe (but have
> > not proved yet) that it may not be necessary, and that CSS based
> > resources can be preloaded without it, at least for the majority
> > of cases.
> >
> > The HTML preloader can keep track of tag names, IDs and class
> > names it encounters (and whether they contained text). A CSS
> > preloader can then scan CSS tokens, find resources, and assuming
> > they have a simple selector, see if they should be downloaded and
> > if so, kick off that download.
>
> The key point is that font resources defined by @font-face rules are
> "load on demand". So if a document never *uses* a font family, not
> font resource loading will occur.
>

I know and I believe that we can predict that "on demand" behavior with
high accuracy in cases where the selector of an element that uses the
font-family is a simple one, and is not overridden by a later CSS rule.

e.g. for
"""
@font-face {
    font-family: superfont;
   ...
}

h3 { font-family: superfont; }
"""

The HTML preloader can keep track of tag names (and if they contained
text), therefore "know" the page contains an h3 tag with text in it, and
once the CSS rule using the font-family is encountered, a download can be
kicked off. The same is true for IDs and class names.


> > The tricky parts would be:
> > * CSS rules that get overridden further down the line.  I need to gather
> > data about how often that happens, since that may trigger needless
> > downloads.
>
> You're thinking of *style* rules. An @font-face rule can't be
> overridden, except indirectly by defining another rule that
> effectively masks an earlier one.
>

Yes, but in the above example, if a later rule was " h3 { font-family:
systemfont;}", that would make the download unnecessary.


> > * Complex selectors that trigger resource download - Keeping track of
> > complex relationships won't be feasible, so such resources won't be
> > preloaded. Again, need data.
>
> A preload hint on an @font-face rule would indicate that a font
> should be loaded independent of whether it's used in the current
> document.
>

I understand, and I believe we can do that optimization without an opt-in
hint for the majority of cases.


>
> > * Unicode ranges for text - They would be harder to track. Maybe we can
> > flag tokens with popular ranges, but it's trickier.
>
> The 'unicode-range' descriptor defines which face with a font family
> is *used* and hence, which font resource would be loaded. With a
> preload hint, the loading would occur but the 'unicode-range' value
> would still dictate when it's used.
>

I'm talking about how we can provide that optimization without the opt-in
hint. If my understanding is correct, when 'unicode-range' is present, we
should download the font only if that unicode range is used in the DOM
element that the font applies to.
Keeping track of that in the preloader may be possible for popular ranges,
but would be limited and would add complexity.


>
> The key problem a preload hint would solve is that the decision
> about whether to use a font or not happens fairly late in the page
> loading process. The hint would simply short circuit the "is this
> font used?" process and add it to the load queue.
>
> Cheers,
>
> John Daggett
> Mozilla Japan
>
>