W3C home > Mailing lists > Public > www-style@w3.org > April 2015

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

From: Florian Rivoal <florian@rivoal.net>
Date: Mon, 13 Apr 2015 21:48:33 +0200
Cc: www-style <www-style@w3.org>
Message-Id: <A241A1B2-754B-4171-9AEA-B2F51C56D7A1@rivoal.net>
To: John Daggett <jdaggett@mozilla.com>

> On 13 Apr 2015, at 07:47, John Daggett <jdaggett@mozilla.com> wrote:
> 
> 
> I'd like to propose a simpler property for controlling font display
> while downloadable font resources are loading. I think the previous
> proposal [1] is overly complex and the value names aren't terribly
> intuitive. 

As I said on the call, I agree that the explicit timeout-based behaviors bring
in quite a bit of complexity, for no obvious gain, and that we could
cover what's actually useful through a few keyword based values.

However, I only partly agree with you about what the
keywords should be and what they should do.


> The 'font-loading-display' property below gives authors an
> effective way to control this:
> 
>   font-loading-display: auto | fallback | blank-fallback | blank
> 
> Value definitions:
> 
>   auto
> 
>   The user agent selects what to display while fonts are loading for a
>   particular text element, based on the optimal balance between
>   displaying some form of text and laying out the page multiple times.
> 
>   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.

These first 2 behaviors are useful.

>   blank-fallback
> 
>   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 available a small time later (e.g. 3 seconds),
>   display using the fallback font. After the font
>   resource is loaded, display text using the font resource.
> 
>   blank
> 
>   For text content that uses a currently loading font resource,
>   initially display text transparently using some form of fallback font.
>   After the font resource is loaded, display text using the font
>   resource. In situations where font loading takes an excessive amount
>   of time, user agents should display text using fallback fonts.

I am not convinced that we should expose the difference between these
2 values. "blank" should be specified so that UA can vary how they
handle the case where the resource doesn't load or takes too long, and
can at their discretion do one or the other of the two behaviors you have
described. But I don't think it's worth letting authors/users chose
between these two.

I'm even tempted to say we don't need either, and this can entirely fall
under the things allowed by auto, but to the extend that browser
may pick "fallback" as the default value (like IE does), maybe
it is useful as a separate value. I'll keep it for now, but I wouldn't
object to it being removed.

> I think it's much, much simpler to have just a property and avoid the
> complexity for authors and implementers involved with having both a
> property and an @font-face descriptor.

This seems orthogonal to the rest of the discussion. Out of a property and
a descriptor, if we should only have one, I agree it should be the property,
but I not not sure what's so bad about having a descriptor as well.

> I also think the 'optional' value is an unnecessary addition. It's
> subtly more complex to define and implement than the spec writers assume
> and it introduces a certain amount of randomness to how text displays
> for a page, since the usage will be dictated by implementation resource
> constraints. Authors that really want to implement this behavior can
> achieve something similar with the Font Loading API instead.

I disagree. Yes, there are subtle timing issue that may cause the page to render
one way or another. But it is specifically to let authors inform the UA that is is OK
for the page to be rendered one way or another. There is a preferred font to be used
if available, but it is sufficiently non critical that it should neither be blocking nor cause
a relayout once it becomes available, and that speed and stability are to be prioritized.

So I'd go with something like this:

font-loading-display: auto | fallback [refresh | no-refresh]? | blank

 - Florian
Received on Monday, 13 April 2015 19:48:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC