Re: [css-font-loading] controlling font loading display

Florian Rivoal wrote:

> >   blank-fallback
> >
> >   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 available a small time later (e.g. 3
> >   seconds), display using the fallback font. After the font resource
> >   is loaded, display text using the font resource.
> >
> >   blank
> >
> >   For text content that uses a currently loading font resource,
> >   initially display text transparently using some form of fallback
> >   font. After the font resource is loaded, display text using the
> >   font resource. In situations where font loading takes an excessive
> >   amount of time, user agents should display text using fallback
> >   fonts.
>
> I am not convinced that we should expose the difference between these
> 2 values. "blank" should be specified so that UA can vary how they
> handle the case where the resource doesn't load or takes too long, and
> can at their discretion do one or the other of the two behaviors you
> have described. But I don't think it's worth letting authors/users
> chose between these two.

I'm not quite clear on what you mean. Are you saying you want 'auto' to
be something similar to 'blank-fallback' above? If 'auto' implies
existing browser defaults, then not having 'blank-fallback' leaves
authors who desire consistent behavior across implementations with
'fallback' or 'blank'.

> > I also think the 'optional' value is an unnecessary addition. It's
> > subtly more complex to define and implement than the spec writers
> > assume and it introduces a certain amount of randomness to how text
> > displays for a page, since the usage will be dictated by
> > implementation resource constraints. Authors that really want to
> > implement this behavior can achieve something similar with the Font
> > Loading API instead.
>
> I disagree. Yes, there are subtle timing issue that may cause the page
> to render one way or another. But it is specifically to let authors
> inform the UA that is is OK for the page to be rendered one way or
> another. There is a preferred font to be used if available, but it is
> sufficiently non critical that it should neither be blocking nor cause
> a relayout once it becomes available, and that speed and stability are
> to be prioritized.
>
> So I'd go with something like this:
>
> font-loading-display: auto | fallback [refresh | no-refresh]? | blank

I'm assuming 'fallback no-refresh' is defined to mean "use the
downloadable font if it's already available", similar to 'optional' in
the original proposal. The 'refresh' value here is unnecessary since you
can simply assume the absence of no-refresh implies refresh.

The subtle assumption here is that there's a natural "already available"
state for fonts (e.g. fonts in data URL's or in locally cached font
resources) such that a font can be immediately, synchronously activated
when needed. I don't think we can guarantee that and the Font Loading
API implies that an async font load is always required for font
resources, even if the turnaround is almost instantaneous (see the
algorithm for FontFace.load()). So by default *no* font on the page will
be available, even if loading doesn't involve a network request.

You can already see this behavior comparing Chrome vs. Firefox for data
URL fonts. Firefox loads font data URL's synchronously while Chrome does
not. So with Firefox you won't see any flash of blank text, while in
Chrome you may.

I think you could make 'blank-fallback no-refresh' work and that may be
sufficient for the imagined use cases. This would mean initially display
text transparently using some form of fallback font. If the font loads
before the timeout, display text using the font resource. After the
timeout, display text with the fallback font and don't switch to the
downloaded font after the load completes.

Cheers,

John
​