Re: [css-fonts] Proposal for standardizing font timeout behavior

Thanks for bringing it up at TPAC! :)

On Tue, Oct 28, 2014 at 3:45 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> TPAC discussion led to some questions:
>
> 1. "optional" might be doable with Resource Hints instead - jdaggett
> wants us to investigate this.
>

Unfortunately neither "optional" nor "swap" is possible with RH.

The root problem is that there is no JS event or callback for "I'm ready to
paint this text block, tell me what to do" -- note that "ready to paint
text" has no relation to the state of the font request, instead it simply
indicates that the browser *could* paint the text at this point in time. If
we had such a callback, then we could implement optional+swap with Font
Events API, alas...

That said, even if we did, it would still be a very involved affair and
fast text rendering is a big enough use case that, I would argue, warrants
a dedicated CSS API to make these behaviors simple to implement and
customize.


> 2. We need to define when the timeout starts counting.
>

All performance timers are tied to startTime defined in NavigationTiming, I
think we should do the same:
http://w3c.github.io/navigation-timing/#startTime-attribute

Effectively, time starts running the moment the navigation is triggered.


> 3. We probably need an "auto" value for letting the UA do what it
> wants, particularly as browsers seem to have behavior that is subtly
> more complex than what is being defined here.  For example, jdaggett
> said that Firefox's behavior is actually that when the initial 3s
> timeout expires, if the font has started downloading, it sets a second
> timeout that lets it go on a little longer.
>

It would be really nice if we could explain default UA behaviors via
exposed primitives. If the current primitives are not sufficient, then
perhaps we should consider extending those instead? Or, consider changing
FF behavior to use defined primitives? We need less magic in the platform.

ig