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

Florian Rivoal wrote:

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

Ah, ok. I think we're actually describing something similar. In my mind
the distinction between 'blank-fallback' and 'blank' is that
'blank-fallback' would show the fallback font relatively quickly, with
the risk of a flash of unstyled text, while 'blank' would signal the
author's desire to wait as much as possible for the font load to
complete. But if you look closely at what I described as 'blank', I
don't think a user agent should ever "wait forever" as Safari does now.
The distinction I'm making is about author intent but the behavior is
really only about whether the time to wait for the font is shortish or
longish.

I think you want to have something that's in between 'fallback' and
'blank', so that authors can specify behavior that matches what
Chrome/Firefox does today.

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

The first time you need any information from any @font-face rule font
it's *not* loaded (i.e. FontFace.status == "unloaded"). When laying out
text, there's not a "you check if it's there or not" step but rather a
"you need to use a font" which may or may not involve an async operation
if a downloadable font is involved. Only *after* that step does the
state of the font change to "loading".

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

Stylesheet loading blocks rendering. So the data URL is available but
the question is whether the URL load is a sync or async operation. If
it's always an async operation then 'optional' or 'blank no-refresh'
will *never* display the downloadable font. That's the downside of this
value, you're subtly requiring sync operations to get the "use if
available" behavior.

Both Webkit and Gecko implement a form of activated font caching that
makes it simpler to implement this but I don't think it's reasonable to
effectively *require* this to get this feature to function correctly.

Cheers,

John

​