Re: [css-font-loading] font-loading-display F2F discussion summary

On Thu, May 21, 2015 at 5:56 AM, John Daggett <jdaggett@mozilla.com> wrote:
> During the past two days at the CSSWG F2F there were two discussions of
> how to control the display of downloadable fonts while fonts are
> loading. See below for the IRC log of the discussion from both days.
>
> There were two resolutions, I've summarized these with a rough sketch of
> spec text.
>
> 1. Control is an @font-face rule descriptor, not a property
>
> 2. Values are as defined below, with the exact value names to
>    be worked out later:
>
>    font-loading-display: block | swap | fallback | optional
>
>    Value definition (with my alternate value names):
>
>    block (show-blank)
>
>    For text content that uses a currently loading font resource,
>    initially display text transparently using some form of fallback
>    font. If the font is still unavailable 3s later, display using the
>    fallback font. After the font resource is loaded, display text
>    using the font resource.
>
>    swap (show-fallback)
>
>    For text content that uses a currently loading font resource,
>    immediately display text using a fallback font instead (i.e. the
>    font that would be used if the font resource was unavailable).
>    After the font resource is loaded, display text using the font
>    resource.
>
>    fallback (conditional)
>
>    For text content that uses a currently loading font resource,
>    immediately display text using a fallback font instead (i.e. the
>    font that would be used if the font resource was unavailable).
>    If the font resource is loaded within 3s from the time the load
>    begins, display text using the font resource. Otherwise, leave the
>    text as it is, displayed in the fallback font.
>
>    optional (conditional local)
>
>    For text content that uses a currently loading font resource,
>    display text using font resource if it loads from cache (very
>    short timeout), otherwise use the fallback font instead. The
>    'optional' value allows UA to not continue loading the font
>    for the next time.
>
> Note: the 'optional' value was not sufficiently defined in the minutes,
> see below.
>
> Using a timeline to compare these values, we have:
>
>   block:
>     blank ==> load within 3000ms ==> font
>     blank ==> load after 3000ms ==> fallback ==> font
>
>   swap:
>     fallback ==> font
>
>   fallback:
>     fallback ==> load within 3000ms ==> font
>     fallback ==> load after 3000ms ==> fallback (no change)
>
>   optional:
>     fallback(?) ==> load within 100ms ==> font
>     fallback(?) ==> load after 100ms ==> fallback (no change)
>
> Issues:
>
> * Is there an 'auto' value here that allows user agents to define the
>   default behavior? Or the default value is...?

Yes, there's an "auto" value.  All the proposals so far have included
one, it just wasn't interesting to talk about in the meeting, so
wasn't included.

> * The conditional display values, 'fallback' and 'optional', need a lot
>   more details defined.

I don't see how "fallback" needs any more details.  You seem to have
described it just fine, above.  block/swap/fallback are all easily
describable with the concepts of "blank period" followed by a "swap
period" followed by just giving up and marking the font as failed for
the rest of the page's lifetime; they just vary on what (possibly
infinite) duration to assign to the first two periods.  "block" is
~3s/infinite, "swap" is 0s/infinite, "fallback" is 0s/~3s.

> For 'optional', during the epsilon period when
>   fonts are pulled out of the cache, is blank or fallback text
>   displayed? I think blank text makes more sense.

I don't have a strong opinion on this.  If you do start painting
before the epsilon expires, doing blank vs fallback won't have any
effect on flicker (blank is painted with the fallback's geometry).  On
the other hand, it's only for an epsilon, so the downside of blank
text is pretty darned small, and probably overridden by the downside
of a FOUT when the font is retrieved successfully.

> Are font loads after
>   the timeout aborted? Can user agents skip the load given network
>   conditions (e.g. networks with known max bandwidth)?

This was discussed; it'll be up to the UA, which can use whatever
knowledge it has of the ambient network conditions to make this
choice.  I plan to have very explicit language in the spec that this
value might mean the font is not used at all for some users.

> If the font loads
>   can be aborted/skipped, the 'optional' value is equivalent to
>   disabling the use of this font across *all* pages. This would be the
>   same as authors simply not using fonts for low-bandwidth situations --
>   is this really the right way for authors to express this?!?

It seems like a pretty reasonable way to express it, imo.  Do you have
better suggestions?  What are your reservations with this approach?

> * As defined, I think the 'optional' value is what Florian was
>   advocating for but I don't think it's what some of the original Google
>   folks wanted. When this value was first described to me it was
>   presented as "we don't ever want to see a flash of anything" value,
>   such that fonts are either available or not and there's no second
>   reflow of text. I think the intended use case was for very
>   perf-sensitive pages.

Yes, this is roughly what Florian was outlining. I'll verify with our
folks that this approach matches our desires, but I'm pretty sure it
does.

> * The use of timeouts based on the timing of resource loads does not seem
> like
>   the right approach for author controlled behavior. The implicit font
>   loading behavior of @font-face fonts means that they usually are
>   queued up behind other resources on the page. The more resources on
>   the page the longer it will be until those font loads start. I think
>   an author-defined control should be based on timeouts correlated with
>   the user-perceived page load time. For example, time since
>   navigationStart. I think this is actually closer to the behavior that
>   several CSSWG members seem to be advocating.

I'm not a fan of this.  It means that fonts which aren't even used at
initial page load are basically immediately penalized.  This feels
like a bad behavior, and also doesn't match current behavior.

If this was *paired with* a preloading hint, I'd be comfortable with
starting the timer from the time the hint is seen, or something
similar.  But by itself, with font loads triggered by use, I'm not a
fan.

> * I think there's a big potential for the conditional display values,
> 'fallback'
>   and 'optional', to produce ransom note effects with common usage
>   scenarios. Fonts are used as families, not simply as single faces. If
>   a page uses a combination of regular, bold and italic faces, timeouts
>   with some of these individual faces will produce text displaying in
>   a mixture of fonts (e.g. bold text in the downloadable font, regular
>   text in the fallback font).

Ooh, good point.  Perhaps we should tie the behavior together for a
given family: if any part of the family displays, it should swap in
the rest regardless.

> * I really think this needs to be implemented in conjunction with some form
> of
>   preload hint, since the late loading behavior of fonts is a major
>   reason authors are asking to control behavior during the page
>   load phase. The control we're discussing here is only half the
>   solution.

I'm not opposed to that *as well*.  Alternately, we can just lean on
script for this; it's super-simple to kick off a .load() on the fonts
you need right away, and thus start their timers.

> * Another concern I have is that I'm not sure how interoperable these values
>   will be in practice. Browser implementations such as iOS Safari are
>   relatively conservative about the number of times a given element is
>   reflowed during the loading process. The natural process of coalescing
>   reflows will have the effect of increasing the perceived timeouts
>   associated with downloaded fonts. The more conservative the browser is,
> the
>   longer the timeout will end up being.

Sure, but I doubt this'll end up being a huge difference in practice.

> Comments:
>
> While I understand the use case for the conditional values, I think
> their use in practice will be problematic. That was the reason I was
> advocating during the Tuesday discussion that we leave this
> functionality to authors using script, at least for the initial version.
> Based on the conditions that script users come up with, we can then
> attempt to mimic those values in new values for font-loading-display.

The WG was convinced that we can define useful values right now;
authors can always come up with their own behavior, but it didn't seem
sufficiently controversial or difficult to define some basic behaviors
now.

> I don't really see a need for the 'swap' value.

Interesting, because it's the one that came from your proposal. ^_^
(You called it "fallback", but the WG and I agreed that "swap" was
better for your "always swap" behavior and "fallback" for my "only
swap for a limited time" behavior.)

> I would prefer to have
> the "show blank text initially" value take some sort of short/long
> modifier, as Florian suggested before. The "short" modifier would be
> very close to 'swap' but the flash of fallback would happen less if you
> give it a small "show blank text" period. Similarly, the current
> proposal eliminates the value for authors that want something closer to
> current Safari behavior. I think allowing a longer timeout for font
> resources that are really required is important.

I'm fine with considering an epsilon blank period for the "swap"
value.  I'll add an issue to the draft and ask for implementation
experience to help settle the issue when I update the spec today.

~TJ

Received on Friday, 22 May 2015 17:19:32 UTC