Re: [css-font-loading] font-loading-display F2F discussion summary

> On 21 May 2015, at 08:56, John Daggett <jdaggett@mozilla.com> wrote:
> 
> There were two resolutions, I've summarized these with a rough sketch of
> spec text.

In general, your summary is accurate. However, we also had a white board
drawing / comparison table, which clarified things a lot, and the minutes
are a somewhat condensed version of what we said, which may miss some
nuances, so I'll clarify the bits where you missed some info.

> 1. Control is an @font-face rule descriptor, not a property

Correct.

> 2. Values are as defined below, with the exact value names to
>   be worked out later:
> 
>   font-loading-display: block | swap | fallback | optional
> 
>   Value definition (with my alternate value names):
> 
>   block (show-blank)
> 
>   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 unavailable 3s later, display using the
>   fallback font. After the font resource is loaded, display text
>   using the font resource.

Almost. 2 small clarifications;
1) the transparent text to be used should specifically use the
metrics of the fallback font that will be used if we reached the
3s timeout, to limit unnecessary relayouts.

2) "3s" is just a general guideline, the UA may decide on a
different duration. For example, it may decide that on a
low-bandwidth / weak-cpu device, the user is accustomed
to slower things, and a delay somewhat longer than 3s would
be more appropriate.

>   swap (show-fallback)
> 
>   For text content that uses a currently loading font resource,
>   immediately display text using a fallback font instead (i.e. the
>   font that would be used if the font resource was unavailable).
>   After the font resource is loaded, display text using the font
>   resource.

correct.

>   fallback (conditional)
> 
>   For text content that uses a currently loading font resource,
>   immediately display text using a fallback font instead (i.e. the
>   font that would be used if the font resource was unavailable).
>   If the font resource is loaded within 3s from the time the load
>   begins, display text using the font resource. Otherwise, leave the
>   text as it is, displayed in the fallback font.

correct, except as above, 3s is a guideline. The exact duration is
up to the UA.

>   optional (conditional local)
> 
>   For text content that uses a currently loading font resource,
>   display text using font resource if it loads from cache (very
>   short timeout), otherwise use the fallback font instead. The
>   'optional' value allows UA to not continue loading the font
>   for the next time.

Correct (see clarification below about what happens during
epsilon).

In addition, the UA may also not even start the download
at all (more details below)

> Note: the 'optional' value was not sufficiently defined in the minutes,
> see below.
> 
> Using a timeline to compare these values, we have:
> 
>  block: 
>    blank ==> load within 3000ms ==> font
>    blank ==> load after 3000ms ==> fallback ==> font
> 
>  swap: 
>    fallback ==> font
> 
>  fallback: 
>    fallback ==> load within 3000ms ==> font
>    fallback ==> load after 3000ms ==> fallback (no change)
> 
>  optional:
>    fallback(?) ==> load within 100ms ==> font
>    fallback(?) ==> load after 100ms ==> fallback (no change)
> 
> Issues:
> 
> * Is there an 'auto' value here that allows user agents to define the
>  default behavior? Or the default value is...?

Yes, there is an auto value. It is the initial value, and has the expected
semenatics: UA defined behavior, possibly but not necessarily picked
from one the the explicit keywords. It was explicitly mentioned during
the meeting, but maybe that didn't make it to the minutes, as we went
over it very briefly since it was completely non-contentious.

> * The conditional display values, 'fallback' and 'optional', need a lot
>  more details defined. For 'optional', during the epsilon period when
>  fonts are pulled out of the cache, is blank or fallback text
>  displayed? I think blank text makes more sense.

The behavior that was described on the whiteboard, was to show
the fallback during the epsilon. Since it was explicitly described
that way, presumably all the people present in the room agreed to this,
but we did not discuss this point. Personally I don't have a strong
preference, epsilon should be short enough that this doesn't matter much.

> Are font loads after
>  the timeout aborted?

We resolved that the UA is allowed to not download the fonts for optional.
All other values we resolved to add were described as requiring the download
to continue.

It was suggested that fallback should be allowed to abort the download
once it reaches the final phase, but this proposal didn't catch on.

Obviously, since the UA is the agent of the user, there may be a mode that
disables downloadable fonts, just like some browsers have a mode that
disable downloading of images. But in the context of this descriptor,
"optional" is the only value that allows the UA not to download the font.

> Can user agents skip the load given network
>  conditions (e.g. networks with known max bandwidth)? If the font loads
>  can be aborted/skipped, the 'optional' value is equivalent to
>  disabling the use of this font across *all* pages. This would be the
>  same as authors simply not using fonts for low-bandwidth situations --
>  is this really the right way for authors to express this?!?

In the case of "optional" (and only in that case), this allows UA
to never download the fonts. Since the author has explicitly
indicated that the font is a nice-to-have but not required
embellishment, allowing UAs to avoid wasting (potentially
expensive) bandwidth was considered desirable.

> * As defined, I think the 'optional' value is what Florian was
>  advocating for but I don't think it's what some of the original Google
>  folks wanted. When this value was first described to me it was
>  presented as "we don't ever want to see a flash of anything" value,
>  such that fonts are either available or not and there's no second
>  reflow of text. I think the intended use case was for very
>  perf-sensitive pages.

I cannot speak for Google, but I am happy with it the way it is,
and believe most if not all people in the room were as well.

> * The use of timeouts based on the timing of resource loads does not seem like
>  the right approach for author controlled behavior. The implicit font
>  loading behavior of @font-face fonts means that they usually are
>  queued up behind other resources on the page. The more resources on
>  the page the longer it will be until those font loads start. I think
>  an author-defined control should be based on timeouts correlated with
>  the user-perceived page load time. For example, time since
>  navigationStart. I think this is actually closer to the behavior that
>  several CSSWG members seem to be advocating.

As I mentioned about, the value of the timeouts are meant as guidelines, not normative
values, so some flexibility is already allowed, but even then you make a valid point.
I think this could be worth a separate discussion.

> * I think there's a big potential for the conditional display values, 'fallback'
>  and 'optional', to produce ransom note effects with common usage
>  scenarios. Fonts are used as families, not simply as single faces. If
>  a page uses a combination of regular, bold and italic faces, timeouts
>  with some of these individual faces will produce text displaying in
>  a mixture of fonts (e.g. bold text in the downloadable font, regular
>  text in the fallback font).

There are 2 cases here:

1) headers use swap and body text uses fallback. The final look of the page may
vary depending whether timeouts are hit, but this is ok, as it matches author intent.

2) body text uses several fonts, all with "fallback" (or conditional) . Some load and some don't. This is
indeed undesirable, very good point.

Here is a suggestion how to fix this. Several font faces could be tied together
either with:
 font-group-name: <ident>
or by extending font-loading-display like this
  font-loading-display: [auto | block | swap | fallback  | optional] <ident>?

if <ident> is omitted, the behavior is the same as described so far.

If it is present, the entire group must be used (or not) atomically. If one
of the fonts cannot be loaded at all or on time, then none of the fonts in the
group can be used.

This is just a 2 minute suggestion, so don't read too much into it, but
we can probably solve this problem with something along these lines.

> * I really think this needs to be implemented in conjunction with some form of
>  preload hint, since the late loading behavior of fonts is a major
>  reason authors are asking to control behavior during the page
>  load phase. The control we're discussing here is only half the
>  solution.

This was not discussed during the meeting as far as I can remember. 

> * Another concern I have is that I'm not sure how interoperable these values
>  will be in practice. Browser implementations such as iOS Safari are
>  relatively conservative about the number of times a given element is
>  reflowed during the loading process. The natural process of coalescing
>  reflows will have the effect of increasing the perceived timeouts
>  associated with downloaded fonts. The more conservative the browser is, the
>  longer the timeout will end up being.

This was not discussed during the meeting as far as I can remember. 

> Comments:
> 
> While I understand the use case for the conditional values, I think
> their use in practice will be problematic. That was the reason I was
> advocating during the Tuesday discussion that we leave this
> functionality to authors using script, at least for the initial version.
> Based on the conditions that script users come up with, we can then
> attempt to mimic those values in new values for font-loading-display.

I am not happy with requiring scripts for these. I think the  ransom-note
effect you mentioned earlier is a valid point, and we should
try to address it. But  but other than that, I like it and want it the way it is.

> I don't really see a need for the 'swap' value. I would prefer to have
> the "show blank text initially" value take some sort of short/long
> modifier, as Florian suggested before. The "short" modifier would be
> very close to 'swap' but the flash of fallback would happen less if you
> give it a small "show blank text" period.

I actually think swap is actually the most useful value, and that blank
should mostly be limited to icon fonts and "super important brand fonts, such
as the coca cola logo" cases.

This is how the web works in general: layouts are built progressively
as resources get downloaded. If you have everything you need early
(and authors should spend significant effort to make sure that's the case),
then you get the final layout early, with minimal or no trashing.
But if you don't, showing something, even incomplete, is generally much
better than keeping (large portions of) the screen blank.

> Similarly, the current
> proposal eliminates the value for authors that want something closer to
> current Safari behavior. I think allowing a longer timeout for font
> resources that are really required is important.

The consensus in the room was that this is not a value we want to
give authors, as it is really user hostile.

We mentioned one alternative solution that may be useful to the
people who are most likely to request this: having "none" as a generic font
family, always available, and transparent. Maybe this could be used
as the fallback font after an icon font which uses arbitrary code points
for its icons.

But that's also a potential footgun, so maybe we shouldn't have it,
or give it a very long and obnoxious to type name (yes-i-really-want-invisible-text).

- Florian

Received on Friday, 22 May 2015 00:13:45 UTC