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

> On 15 Apr 2015, at 08:48, John Daggett <jdaggett@mozilla.com> wrote:
> 
> 
> 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 think if an author says 'blank' the browser should be allowed to do
either what you described as 'blank' or what you described as
'blank-fallback', or other close variants. Outside of error handling
(I'm using the term broadly), the intent is the same: don't show the text
until you have the font. Error handling does vary, but I think this not
necessary to expose, and I'm ok with letting browsers decide for themselves
how they are going to handle it.

If you want to dig a bit further, I'd actually be ok with allowing
authors to ask for blank-fallback in a browser that does blank, but not
the other way around. Content that never shows is bad. So actually,
while I'm all for giving freedom to browsers to decide how and how long
they want to wait before falling back, I am tempted to actually require
that they must eventually show the content.


If we agree we only need one type of blank (with some implementation
flexibility), a separate question is whether 'auto' should mean 'blank',
in which case we don't need separate keyword for 'blank', or if it can
mean 'blank' or 'fallback', in which case we do. I used to favor the
former, but I've changed my mind.

> > 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.

Correct

> The 'refresh' value here is unnecessary since you
> can simply assume the absence of no-refresh implies refresh. 

Right. "fallback" and "fallback refresh" indeed do the same. No need for both,
I was sloppy.

> 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.

I was not thinking in terms of synchronous or asynchronous APIs. Maybe
I'm being naïve here, but I was thinking that from a layout point
of view, the first time you need any information from the font, you check
if it's there or not (where "it's there" means "the layout engine can use
it). If it's there, you use it, if it's not, you fallback and remember having
done so.

From that point of view, it doesn't really matter when events fire.

> 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 am not sure this is a problem. If your data url is in a part of the
stylesheet that's not done downloading yet and you're already laying out,
then the font is not available, so you fallback. So there's no strong
guarantee you'll get the font you want anyway. It's certainly preferable
if the browser can manage to prepare a data url font fast enough to be ready
for layout, but if not, they author said they're ok with the fallback. If
they're not, they can use 'blank'.

> 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.

Good point, the no-refresh behavior makes sense on blank (again,
I am no distinguishing between blank and blank-fallback) as well.


font-loading-display: auto | [ fallback | blank ] no-refresh?