Intent to Implement: User Agent Intervention for "font-display: auto"

[Takashi Toyoshima]

Contact emails

toyo...@chromium.org, kenji...@chromium.org

Spec

http://tabatkins.github.io/specs/css-font-display/ CSS Font Rendering Controls Module Level 1

http://bit.ly/user-agent-intervention User Agent Intervention (not a spec but explains what’s intervention)

Summary

CSS Font Rendering Controls Module defines “font-display” property to control Web Fonts timeouts for fallback and swap. If users specify “auto” or does not specify the “font-display”, the browser can pick the best strategy. I will introduce an adaptive timeout that is aware of the quality of the network connection as a light User Agent Intervention. This intent aims to implement a simple logic to adopt “swap” mode when faced with  “auto” on a 2G cellular network. In the future, I’m planning to improve the signal.

Motivation

On 2G cellular networks, 25% of Web Fonts loading hit the 3 seconds fallback timeout even if the font size is smaller than 1KB. Unfortunately, this means that a font may block the first meaningful paint unnecessarily for 3 seconds.

Interoperability and Compatibility Risk

At this point, each browser implements different approach to fire each timeout, and this change does not introduce any spec violation.

Also, we discussed this proposal at intervention-dev@ beforehand and received positive feedback.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Technically yes, but this is meaningful only on mobile platforms. WebView does not support it for now since Network Information API on which we rely is under development (crbug.com/520088).

OWP launch tracking bug

crbug.com/515343

Link to entry on the feature dashboard

Not yet.

Requesting approval to ship?

No.

--

Takashi Toyoshima
Software Engineer, Google

[Dimitri Glazkov]

What was the conclusion of the discussion around closing the feedback loop for the developers? For example, if you sent me (web developer) a some header/hint, indicating that you are unlikely to load my web fonts, I should be able to choose to never send them in the first place.

:DG<

[Kenji Baheux]

The proposed intervention is to turn font-display: auto (implicit value) into font-display: swap.

font-display: swap means that we would:

1. fallback to the system font (unless the web font is "readily" available) and kick a request for the web font
   
2. swap to the web font when it becomes available

An alternative idea would be to turn font-display:auto into font-display: optional where we would:

1. fallback to the system font (unless the web font is "readily" available) 
   
2. let the page load run its course
3. optionally kick a request for the web font so that it's there on the next visit

So, in both case we do intend/hope to load the web font, just not block on it.

In terms of closing the developer feedback loop, we are aiming for the following:

1. use the network quality estimator instead of the connection type
2. leave some head room on the decision to bail out if a web font is almost ready (i.e. the developer did the right things: use link rel preload or the font loading api early on, woff2/... small web font)
3. respect explicit font-display hints within reason (i.e. the developer asked for font-display: block and did the right things[tm]).

In parallel to this, I'm planning to outreach for feedback on font-display itself to make sure that this all work in practice.

[Ilya Grigorik]

On Mon, Dec 7, 2015 at 8:55 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

What was the conclusion of the discussion around closing the feedback loop for the developers? For example, if you sent me (web developer) a some header/hint, indicating that you are unlikely to load my web fonts, I should be able to choose to never send them in the first place.

We don't want to discourage use of web-fonts. Instead, the recommended best practice for developers would be to adopt "font-display: swap" as a default, because blocking text rendering is an anti-pattern, regardless of connection quality.

[Rick Byers]

This sounds like a great use of interventions to me.

The guidelines discuss the need to specify, guide and report on interventions.  Can you talk about your thoughts on those?  Eg.:

- Where will you document this behaviour? 

- Is there an existing resource that already advocates for techniques that are guaranteed not to hit this intervention?  Eg. I don't see "font-display: swap" mentioned in https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization?hl=en#optimizing-loading-and-rendering.

- How will a site know they've hit this intervention? 

Rick

[Kenji Baheux]

Those are good questions that we'll need to answer for the intent to ship.

I'll work on these while the implementation progress, assuming that we get the 3 LGTMs for this intent to implement.

[Chris Harrelson]

On Wed, Dec 9, 2015 at 5:37 PM Kenji Baheux <kenji...@chromium.org> wrote:

Those are good questions that we'll need to answer for the intent to ship.

I'll work on these while the implementation progress, assuming that we get the 3 LGTMs for this intent to implement.

LGTMs aren't needed for implementation intents. But for the record, I think this is a great intervention to try.

 

On Thu, Dec 10, 2015 at 10:31 AM 'Rick Byers' via blink-dev <blin...@chromium.org> wrote:

This sounds like a great use of interventions to me.

The guidelines discuss the need to specify, guide and report on interventions.  Can you talk about your thoughts on those?  Eg.:

- Where will you document this behaviour? 

- Is there an existing resource that already advocates for techniques that are guaranteed not to hit this intervention?  Eg. I don't see "font-display: swap" mentioned in https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization?hl=en#optimizing-loading-and-rendering.

- How will a site know they've hit this intervention? 

Rick

On Tuesday, 8 December 2015, 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

On Mon, Dec 7, 2015 at 8:55 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

What was the conclusion of the discussion around closing the feedback loop for the developers? For example, if you sent me (web developer) a some header/hint, indicating that you are unlikely to load my web fonts, I should be able to choose to never send them in the first place.

We don't want to discourage use of web-fonts. Instead, the recommended best practice for developers would be to adopt "font-display: swap" as a default, because blocking text rendering is an anti-pattern, regardless of connection quality.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

On Thu, Dec 10, 2015 at 12:34 PM, Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Dec 9, 2015 at 5:37 PM Kenji Baheux <kenji...@chromium.org> wrote:

Those are good questions that we'll need to answer for the intent to ship.

Yes agreed, I hope it didn't sound like I was suggesting otherwise :-).  Definitely proceed with implementation!

[Takashi Toyoshima]

Thank you for deedbacks.

Since there are no serious concerns, I'll start implementation.