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

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

As defined, the 'optional' keyword would always be effectively
determined by whether a font had been loaded by a previous page,
since layout initiates font loads and paint follows shortly after
layout. So 'optional' in practice would be equivalent to "use the
the font if it's already been cached".

The Font Loading API gives authors complete control over when fonts
are loaded, precisely when they are used, and how the "swap" occurs.
The "first paint" event you keep referring to is really "first
layout", since font selection affects layout. If you feel the
missing element is a "first layout" event for a given element, maybe
that's what should be spec'ed instead.

That said, I think trying to spec behavior on "first layout" is
really tricky since the precise timing of this depends on the
incremental layout algorithm used by a browser and that's going to
vary across user agents/devices.

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

Um, so instead we're proposing CSS properties that tweak fetch
parameters?!? ;)

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

This is not what any user agent implements currently. Font load
timers start when layout decides it needs a given font.

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

Ilya, you need to define what the default behavior is. If you don't
want a single, standard behavior, then an 'auto' value is needed
here, which would allow user agents to vary.

If you're going to talk about "primitives" then those primitives
shouldn't be font-specific. The problem here is that you're trying
to specify one small set of behaviors when the larger "how do user
agents load and display resources quickly and efficiently?" is one
big ball of magic.

I think the use of icon fonts would be a good use case example.
How's does waiting on an icon font compare with waiting on a set of
images? Whatever pattern is used for one should probably be similar
to the other since all the reasons to control the layout of fonts
applies just as equally to images, and vice versa. Sometimes images
are progressive enhancement fluff, sometimes they are critical UI
essentials, just like fonts.

Cheers,

John Daggett
Mozilla Japan

Received on Thursday, 30 October 2014 04:23:42 UTC