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

On Thu, Oct 30, 2014 at 1:43 AM, John Daggett <jdaggett@mozilla.com> wrote:
> Ilya Grigorik wrote:
>> However, even with the JS event, defining this behavior would still require
>> quite a bit of JS work on behalf of developer. Personally, I'd still like
>> to see this as a CSS property. Text rendering (aka, communicating actual
>> information on the page) is the bread and butter of the web... It would
>> sure be nice to make delivering a performant text rendering experience
>> simple.
>
> Just to be clear, what's been proposed doesn't actually affect text
> rendering *performance* in any way. It's simply trying to ameliorate
> the effects of poor load performance for fonts on the dynamic layout
> of the page.

Ehh, phrasing.  It can be considered a "performance problem" that your
text is unrendered for 3s or more, even if the rest of your page is
ready.

>> The behavior we're proposing here is not tweaking fetch parameters
>> in any way. To deliver the optimal experience you'd use this
>> alongside Font Events API to kick off an early fetch (from network
>> or cache), and then use these CSS properties to control behavior
>> of text rendering at first layout+paint of each element based on
>> state of the font request.
>>
>> - Font Events API allows me to start the font request sooner
>> - Browser is now racing font request and layout+paint work
>> - Browser gets to layout+paint and uses font-rendering to determine which
>> text rendering strategy it should apply
>>  -- if request has finished, it applies the font and moves on
>>  -- if request is still in flight, it applies specified strategy
>
> I should point out here that the ability to set timeout-sensitive
> behavior on elements is fraught with problems. Consider the example
> of a large document (think HTML5 spec) that uses a downloadable font
> for headings:
>
>   @font-face { font-family: myfont; src: url(myfont.woff); }
>
>   h4 { font-family: myfont, fallback-serif; font-rendering: swap 3s; }
>
> The user agent starts the font load and lays out the first section
> of the document. Headings appear in the fallback font. Because it's
> a large document the font load takes more than 3 seconds, so
> headings in the first section remain in the fallback font. But as
> later sections are laid out, the font *is* available so in those
> sections headings appear in the downloadable font.  But scroll back
> up and the headings remain in the fallback font.
>
> From an implementation viewpoint, you'd need to track this "timed
> out" state for those elements to prevent them switching to the
> fallback font. So when running font matching on reflows you'd need
> to keep track of font availability from the first layout. Ick. This
> doesn't sound like a way of providing performant text rendering.

I talked about this during the meeting already.  It's just an extra
bit of state to prevent inconsistent rendering (you need to consider
this font "not usable" for the lifetime of the page if it exceeds the
timeout).  I couldn't really tell what your objection to this was
during the meeting, and I'm still unclear here.  You make it sound
somehow complicated, rather than one bit you check on the font when
determining which font to use on newly-rendered text.  You already
have to do a check for whether the font with a given name even exists;
this is one more boolean check once the font is found to see if it's
considered "usable" for this page load.

>> > 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.
>>
>> Personally, I'm ok with allowing UAs to customize own defaults. As Tab
>> noted:
>>
>>   FF and Chrome/Opera currently have a default of "mandatory 3s".  IE
>>   has a default of "mandatory 0s".  Safari has a default of "mandatory
>>   <infinite-time-value>".
>
> CSS properties have an initial value which is the same across
> browsers. The descriptors of the @font-face value have default
> values which are the same across browsers. So you need to define an
> initial value of the 'font-rendering' property and a default value
> for the 'font-rendering' descriptor within @font-face rules. In
> fact, to implement what you've described you need slightly different
> values for the property, since I think you want the default value
> for the descriptor to be "whatever the user agent timeout policy is"
> and for the *property* you want an initial value of 'auto' to mean
> "decide based on the 'font-rendering' descriptor value of the font".

Yes, the property definitely needs an initial value that means
"whatever the font says"; thanks for catching that.

> But this is just CSS mechanics, the important thing to decide here
> is whether you're proposing a single browser default timeout
> behavior or not. I actually think requiring some form of timeout
> would be a good idea. I'm guessing the 'mandatory <infinite>' for
> Safari is just a bug not really a feature.

Agreed about Safari, but I'm really fine with the default timeout
behavior being UA-specific.

> I think the additions proposed don't really address the underlying
> problem (font loads happening late or taking too long) and have some
> unfortunate side effects. I think the Font Loading API provides a
> lot of ways authors can address problems associated with slow font
> loading. I'm not really convinced that twiddling timeout behavior
> via CSS is the right solution here.

I don't think you've stated why you think they don't address those
problems.  (If it was in one of the sections of your response I
elided, forgive me.)  The Font Loading API is indeed an all-purpose
solution to any desire for control over font-loading, but the
existence of a low-level API does not automatically negate the
usefulness of a higher-level one that handles some common cases more
simply.  I think that's exactly what this proposal does, with its
three categorizations.

Can you be more specific about why you think either the Font Loading
API is sufficiently simple for these use-cases, or how the categories
we've defined don't offer useful functionality?

~TJ

Received on Thursday, 30 October 2014 15:24:19 UTC