Bail out early from web fonts (Re: [intervention-dev] Intervention deep dive: start the 3s timeout for font-display: block when page load is starting)

[Kinuko Yasuda]

(Re-titling...)

On Wed, Nov 25, 2015 at 6:23 PM, Kinuko Yasuda <kin...@chromium.org> wrote:

(+loading-dev@)

On Wed, Nov 25, 2015 at 5:04 PM, Takashi Toyoshima <toyo...@chromium.org> wrote:

Hi, let me dig up the thread.

Kenji implied the three steps to ship the web font loading intervention. 

 1. ship font-display

 2. ship the bail out intervention

 3. [priority tbd] address the font-display: block loophole.

Now, ksamoaoto@ landed changes for font-display, the step 1 (crbug.com/530015), and I want to drive the step 2.

Basically, my suggestion does not violate the spec, but it would be worth having discussion here.

Design doc: https://docs.google.com/document/d/12yQa0eMhGPO-DDhLb8FCg8ss-MTt8JkTFgEJyoM_4uQ/edit?usp=sharing

This contains some feature plans like using cache information or something, but for now I'd focus on the first step, just using network information, e.g. connection type, and NQE results.

Also here is a link to a preliminary survey on font loading per each cellular network type. The design doc also includes the link, but it would be interesting for developers who ain't familiar to Web Fonts. 

https://docs.google.com/document/d/1f2tcvW72A9haFkCNsVhKgi1iteNrCRHYA7Y_uIautl4/edit

On Thu, Oct 8, 2015 at 5:35 PM, Kenji Baheux <kenji...@chromium.org> wrote:

On Thu, Oct 8, 2015, 6:31 AM Ilya Grigorik <igri...@google.com> wrote:

Practically speaking though.. We still have some plumbing to do to get the intervention delivery stuff in place, so this all may be moot -- as in, we'll have font-display before said intervention?

I think there is a spectrum of interventions. The bailing out intervention probably doesn't need to block on the intervention delivery stuff while the intervention on document.write (tbd) sounds much scarier and would probably benefits from a good intervention infra.

 

ig

On Wed, Oct 7, 2015 at 9:44 AM, 'Dru Knox' via intervention-dev <interven...@chromium.org> wrote:

Eventually, we offer these font-display options as the escape hatch: if you don't want your fonts to be intervened, you can make sure they're well compressed, preloaded, and then set them to block. The goal, as it should be for most interventions, is that our intervening slowly fades into the light as the ecosystem improves.

Thoughts?

Yes, that's basically one of the insight I noted while walking through the original idea:

Perhaps, a simpler(?) alternative idea would be to use these signals to determine if it would be righteous to intervene:

You are not even trying => intervene (3s timeout from page load start).

In other words, you ask for font-display: block but don't try hard enough (poor compression, no preloading), we should still intervene if the user experience can be made noticeably better.

 

You are doing your best, keep the existing 3s timeout.*

In other words, you ask for font-display: block and are doing the right things (good compression, preloading), we'll honour font-display: block because the user experience will be roughly as good as it gets.

* the spec specifies a timeout even in the block case, with 3s as a recommended value.

In fact, if we blindly honoured font-display: block we would be back to square one (loophole). 

That being said, I don't think we need to block anything on this particular intervention:

 1. ship font-display

 2. ship the bail out intervention

 3. [priority tbd] address the font-display: block loophole.

On Tue, Oct 6, 2015 at 11:59 PM Kenji Baheux <kenji...@chromium.org> wrote:

Forking to discuss an intervention idea that came out of "bail out early from web fonts if we know that we'll hit the 3s timeout" (recommend reading for context).

tl;dr: I tried to walk through what the proposal would mean. My conclusion: this seems overly complex to grasp for a developer and IUC, this is targeting the future (font-display: block) = unknown. Shall we just wait to learn how it will be used and the performance implications before considering any intervention?

===============

Kinuko:

"- If font-display: block is specified I'd expect UA waits at least for some secs before showing fallback font. For this one I like the idea of waiting for 3 secs but not from when the font load is started but from when the page load is started (so that if user already waited for long s/he doesn't need to wait further), way: fall back sooner on slow network but not on fast network."

Bryan:

"+1 to not waiting more than 3s from page load rather than 3s from font load.

Ojan:

"If we did this, maybe we don't need to do anything special for 2g/3g?"

===============

I think that the rationale behind this intervention is that with some efforts, one can achieve the same rate of "text displayed with a web font" while minimizing the impact on page load by virtue of offsetting the timeout. Let's walk this through.

My interpretation

"when the page load is started"

A reasonable interpretation is probably: "as soon as the document owner has the opportunity to do something":

on first bytes received (because one could use HTTP link rel=preload)on first bytes from body received (because one could use <link rel=preload> in head)

"3s timeout"

I imagine that in practice this would mean "3s OR ready to paint associated text, whichever comes last.

Afterall, there is no point in timing out if we are not ready to paint the associated text.

"if font-display: block is specified"

This pegs the UA into a mode that potentially limits its ability to optimize the user experience.

If one cares so much about a given font to the point where it can negatively impact the user experience, it seems fair to hold that person to higher standards when it comes to mitigate the downsides.

"Higher standards"

use of Link rel=preload (HTTP or element) to kick the font request asap.
reasonably small size => implies WOFF2 and subsetting

Perhaps, a simpler(?) alternative idea would be to use these signals to determine if it would be righteous to intervene:

You are not even trying => intervene (3s timeout from page load start).You are doing your best, keep the existing 3s timeout.

Is this reasonable?

HTTP link rel=preload headers implies the ability to configure the server which might be tricky at times.<link rel=preload> elements seems relatively reasonable.expecting WOFF2 also seems reasonable (e.g. tooling is available, major font services all support it).this assumes that 3s of network when the page load is starting is roughly equivalent to 3s of network after all render blocking assets have been dealt with (the point at which the UA decides which web fonts it will need). I'm not sure this is a fair assumption.cons: losing the opportunity of doing dynamic subsetting (e.g. dynamic selection via unicode-range or dynamic subset generation via JS)

Edge cases

What about font-display: block fonts that are added/discovered later? Seems obviously wrong to base their timeouts around page load start.Exception to the rule?Fonts in cross origin iframes: should have their own state.

Re: Ojan's comment "If we did this, maybe we don't need to do anything special for 2g/3g"

Originally, I think Kinuko's suggestion was explicitly targeting the font-display: block fonts that might impact Loading.

So we would still need the bailout early intervention for the other cases (no font-display specified, edge case #1...).

Expanding this to all web fonts would probably lead to bad outcomes (i.e. "preload all the fonts to get a chance to see them!" which will surely include unused fonts)

Conclusion

Overall, this feels complex (cf. edge case #1)?

Given that this is targeting the future font-display: block fonts, shall we just wait on learning how it will be used and its performance implications?

Thoughts?

--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/df88e440-d641-40a5-81e1-cc61c1f17346%40chromium.org.

--

-Dru

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAJcfO450yAs8anXJY7%2B0stF0ZBj3B3HUSydXzj0utz8Gy8J6jQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CADWWn7VwiaTK_rU-RbJ4BYCzZ31PSCiayc%2BYxb-m58oA2YUYOA%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAFWCB1kPKWM2sbR90sZkyTEPRKGj3_6ET7Td-0CKXZNxLaEFyQ%40mail.gmail.com.

[Ilya Grigorik]

+tab

Thanks for putting this together, excited to see progress on this! Left a few comments in the doc.

If I'm reading this correctly, the first proposed step here (the "fallback immediately on slow networks like 2G" strategy), is to add an intervention that treats "font-display: auto" as "font-display: swap" for 2G connections -- right?

• We don't need to block on this, but we should also add something to report the violation to the developer.
• While simple to understand, this is tricky for the developer to implement on their own...
• Adding font-display: swap in my CSS is not sufficient because I can't make this property conditional on 2G. =/
• There is no @rule or media property that would allow me to conditionally apply/load CSS based on netinfo.

That said, I'm not sure that exposing @rules or MQ support for netinfo is the right solution here either.. Just thinking out loud.

[Takashi Toyoshima]

Thank you for comments in documents and here.

On Thu, Nov 26, 2015 at 3:29 AM, Ilya Grigorik <igri...@google.com> wrote:

+tab

Thanks for putting this together, excited to see progress on this! Left a few comments in the doc.

If I'm reading this correctly, the first proposed step here (the "fallback immediately on slow networks like 2G" strategy), is to add an intervention that treats "font-display: auto" as "font-display: swap" for 2G connections -- right?

• We don't need to block on this, but we should also add something to report the violation to the developer.

I'm thinking about showing a warning on DevTools console. I think all intervention in Blink should use the same format, and in the future, we should modify DevTools' network throttling to trigger interventions so that developers can easily check slow network behaviors.

• While simple to understand, this is tricky for the developer to implement on their own...
• Adding font-display: swap in my CSS is not sufficient because I can't make this property conditional on 2G. =/
• There is no @rule or media property that would allow me to conditionally apply/load CSS based on netinfo.

I think that's intervention. If developer can control all behaviors, it isn't the browser intervention any more.

At this point, we do not have any confidence that connection type is enough, and will change the behavior to use estimated network quality eventually. Once we learn good strategy in the wild www, we will change the spec so that developer can control font loading in proper way. It could be a conditional CSS based on netinfo.

[Ilya Grigorik]

On Thu, Nov 26, 2015 at 5:52 AM, Takashi Toyoshima <toyo...@chromium.org> wrote:

Thank you for comments in documents and here.

On Thu, Nov 26, 2015 at 3:29 AM, Ilya Grigorik <igri...@google.com> wrote:

+tab

Thanks for putting this together, excited to see progress on this! Left a few comments in the doc.

If I'm reading this correctly, the first proposed step here (the "fallback immediately on slow networks like 2G" strategy), is to add an intervention that treats "font-display: auto" as "font-display: swap" for 2G connections -- right?

• We don't need to block on this, but we should also add something to report the violation to the developer.

I'm thinking about showing a warning on DevTools console. I think all intervention in Blink should use the same format, and in the future, we should modify DevTools' network throttling to trigger interventions so that developers can easily check slow network behaviors.

That's not going to be terribly useful in practice... Intervention is triggered on the user based on connection type, most developers either can't or won't test under those conditions. That's not to say that we shouldn't provide something in DevTools.. but I don't think that throwing a warning is sufficient.

• While simple to understand, this is tricky for the developer to implement on their own...
• Adding font-display: swap in my CSS is not sufficient because I can't make this property conditional on 2G. =/
• There is no @rule or media property that would allow me to conditionally apply/load CSS based on netinfo.

I think that's intervention. If developer can control all behaviors, it isn't the browser intervention any more.

If the developer can't achieve the same behavior as what we're forcing on the user at runtime.. then we've failed both the developer and the user. At a minimum, we must have a plausible route for: we triggered X because Y, to avoid this do A,B,C. 

 

At this point, we do not have any confidence that connection type is enough, and will change the behavior to use estimated network quality eventually. Once we learn good strategy in the wild www, we will change the spec so that developer can control font loading in proper way. It could be a conditional CSS based on netinfo.

Today I guess that would require shifting all font loading into JS-land.. NetInfo + Font Loading API. Not great, but its something.. sg. 

[Kenji Baheux]

I'm hoping that we are aiming at:

The UA forced font-display:swap because the swap would have happened anyway but with an extra 3 seconds of blank text resulting in a worse user experience.

To avoid this follow these best practices:

• Use WOFF2, subsetting and unicode-range to minimize the size and therefore the download time
• Use link rel preload or the Font Loading API to trigger the fonts download as early as possible
• ...

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADXXVKp0jNgb29TPK5DKednzVmupqsxd6223NCPCtFORdL2eRQ%40mail.gmail.com.

[Takashi Toyoshima]

On Fri, Nov 27, 2015 at 3:58 AM, Ilya Grigorik <igri...@google.com> wrote:

On Thu, Nov 26, 2015 at 5:52 AM, Takashi Toyoshima <toyo...@chromium.org> wrote:

Thank you for comments in documents and here.

On Thu, Nov 26, 2015 at 3:29 AM, Ilya Grigorik <igri...@google.com> wrote:

+tab

Thanks for putting this together, excited to see progress on this! Left a few comments in the doc.

If I'm reading this correctly, the first proposed step here (the "fallback immediately on slow networks like 2G" strategy), is to add an intervention that treats "font-display: auto" as "font-display: swap" for 2G connections -- right?

• We don't need to block on this, but we should also add something to report the violation to the developer.

I'm thinking about showing a warning on DevTools console. I think all intervention in Blink should use the same format, and in the future, we should modify DevTools' network throttling to trigger interventions so that developers can easily check slow network behaviors.

That's not going to be terribly useful in practice... Intervention is triggered on the user based on connection type, most developers either can't or won't test under those conditions. That's not to say that we shouldn't provide something in DevTools.. but I don't think that throwing a warning is sufficient.

Agreed. We need a separate discussion about the common infrastructure to control the intervention with intervention-dev@ members. At this point, I prefer to implement the simplest implementation under Finch experiments, then learn what is needed to implement infrastructure incrementally.

I imagine that it would be something like permission bubble + content setting. On the first intervention happening, the UA may popup bubble UI, or show an icon inside address bar or at TLS cert icon's place, then user will be able to disable the intervention on the visiting page there.

• While simple to understand, this is tricky for the developer to implement on their own...
• Adding font-display: swap in my CSS is not sufficient because I can't make this property conditional on 2G. =/
• There is no @rule or media property that would allow me to conditionally apply/load CSS based on netinfo.

I think that's intervention. If developer can control all behaviors, it isn't the browser intervention any more.

If the developer can't achieve the same behavior as what we're forcing on the user at runtime.. then we've failed both the developer and the user. At a minimum, we must have a plausible route for: we triggered X because Y, to avoid this do A,B,C. 

As Kenji said,  my proposal just adapt "font-display: swap" behaviors even for "font-display: auto" on slow networks. Developers do not lose any control of contents with this proposal. So this is good example to experimentally introduce an intervention.

Your conditional CSS idea sounds a proposal to give publishers more controls of font loading. So I feel we should discuss it separately as a CSS Font Rendering Controls v2.

By the way, you also proposed Save-Data Hint. Do you think it isn't enough for developers, or conditional CSS is better?

[Jason Pamental]

From a designer/developer's point of view (and someone who is an advocate of just getting content on screen first and then worrying about style), I think that this effort is hugely important. But pushing control entirely into JS would be a step backward for the notion of Progressive Enhancement. Currently we're not able to handle web font loading and styling fallbacks without relying on JS in some way. CSS font-display is a step in the right direction, but ultimately what is best for the user is the ability to have the control about if web fonts are called at all and how the fallback fonts are styled right in the CSS so there is no reliance on loading/parsing/executing JS. 

That would give the fastest performance, and this sort of intervention would 1) prevent developers from causing harm to the experience by failing to specify (or using font-display: auto) and 2) work with the previously-described CSS implementation so that if the page is rendered with fallback fonts the experience will be maintained.

[Ilya Grigorik]

Thinking about this some more, I think I may have unnecessarily fixated on the 2G bits.. Really, the intervention we're discussing here is any case where the UA has a hunch that the default (font-display: auto) behavior with 3s timeout will be reached before font is downloaded -- e.g. shaky wifi, etc. It just so happens that knowing that the user is on 2G is by itself a high confidence signal that this will be the case.

As such, the guidance to developers shouldn't be to "special case 2G", but to adopt "font-display: swap" as default.. because not doing so ignores all the cases where network delays will result in delayed text rendering. No need for conditional CSS, etc..

On Fri, Nov 27, 2015 at 2:44 AM, Takashi Toyoshima <toyo...@chromium.org> wrote:

By the way, you also proposed Save-Data Hint. Do you think it isn't enough for developers, or conditional CSS is better?

I see that as mostly orthogonal. The developer may adjust what (or, if) fonts they serve if Save-Data is advertised.. but that's a site specific decision.

 

[Takashi Toyoshima]

Thank you for feedbacks.

On Sun, Nov 29, 2015 at 12:26 AM, Jason Pamental <ja...@freshtilledsoil.com> wrote:

From a designer/developer's point of view (and someone who is an advocate of just getting content on screen first and then worrying about style), I think that this effort is hugely important. But pushing control entirely into JS would be a step backward for the notion of Progressive Enhancement. Currently we're not able to handle web font loading and styling fallbacks without relying on JS in some way. CSS font-display is a step in the right

Agreed. But I may misunderstand the next sentence.

 

direction, but ultimately what is best for the user is the ability to have the control about if web fonts are called at all and how the fallback fonts are styled right in the CSS so there is no reliance on loading/parsing/executing JS. 

Are you suggesting that the browser should have a setting to disable Web Font loading completely, and designers should have a control to specify an alternative style in the CSS? This is an analogy of disabling image loading and show alt attribute text instead.

But the goal of the intervention is something smarter and it can be aware of user facing circumstance, e.g. slow and unstable network connection in the commute train, visiting another country for trips, server for ads being very slow temporarily for some troubles, etc.

That would give the fastest performance, and this sort of intervention would 1) prevent developers from causing harm to the experience by failing to specify (or using font-display: auto) and 2) work with the previously-described CSS implementation so that if the page is rendered with fallback fonts the experience will be maintained.

Developers and designers who are interested in web page performance will specify a favorite mode for the font-display. But the 'auto' is intended to be used by developers who ain't, IIUC. That's why 'auto' is default. And for browser vendor, it could be a providing ground to find a better option that will be exposed to the CSS Font Rendering Controls spec in the future.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/a48f06b8-f2eb-4476-a42b-886d8a6f120f%40chromium.org.

[Takashi Toyoshima]

On Tue, Dec 1, 2015 at 4:57 AM, Ilya Grigorik <igri...@google.com> wrote:

Thinking about this some more, I think I may have unnecessarily fixated on the 2G bits.. Really, the intervention we're discussing here is any case where the UA has a hunch that the default (font-display: auto) behavior with 3s timeout will be reached before font is downloaded -- e.g. shaky wifi, etc. It just so happens that knowing that the user is on 2G is by itself a high confidence signal that this will be the case.

Yes. The only reason why I want to use 2G connection as a hunch is that it's almost available in Blink, and that looks a good first trial to understand what happens when we introduce an intervention. I want to improve the signal incrementally with seeing metrics carefully. For now RTT looks an interesting signal, but it isn't available in Blink. I'm discussing with NQE experts in parallel.

As such, the guidance to developers shouldn't be to "special case 2G", but to adopt "font-display: swap" as default.. because not doing so ignores all the cases where network delays will result in delayed text rendering. No need for conditional CSS, etc..

But it will cause FOUT. Is it acceptable? What the 'auto' is intended is not to cause FOUT as possible, but to give up on bad situations where FOUT happens anyway.

On Fri, Nov 27, 2015 at 2:44 AM, Takashi Toyoshima <toyo...@chromium.org> wrote:

By the way, you also proposed Save-Data Hint. Do you think it isn't enough for developers, or conditional CSS is better?

I see that as mostly orthogonal. The developer may adjust what (or, if) fonts they serve if Save-Data is advertised.. but that's a site specific decision.

 

[Ilya Grigorik]

On Tue, Dec 1, 2015 at 12:22 AM, Takashi Toyoshima <toyo...@chromium.org> wrote:

As such, the guidance to developers shouldn't be to "special case 2G", but to adopt "font-display: swap" as default.. because not doing so ignores all the cases where network delays will result in delayed text rendering. No need for conditional CSS, etc..

But it will cause FOUT. Is it acceptable? What the 'auto' is intended is not to cause FOUT as possible, but to give up on bad situations where FOUT happens anyway.

You can play tricks with spacing, be careful about your fallbacks, etc, to minimize impact of FOUT. Over the last year, there has been a noticeable tide towards "we must embrace FOUT" -- e.g. http://ffffallback.com/. 

That's not to say that FOUT is the right strategy in every case. But, I do think it's the right strategy as the default case... and we should make sure that we implement good logic to race the cache + network. 

[Jason Pamental]

Ilya - This is what I've been advocating for years! I think that FOUT _is_ preferable in most scenarios, so long as there is a way (like using the web font loader classes) to target/style the fallback fonts using spacing, line height, size, etc. This can make most of the shift from fallback to web font much less noticeable.

Takahashi - this is what I was trying to explain above: if we have the ability to style fallbacks and trigger those styles automatically, we will always have something in place to preserve the layout during the loading process AND should they fail to load entirely. I wasn't really thinking in terms of a user setting. I hope this is a clearer explanation!

[Takashi Toyoshima]

Let me summarize discussion to confirm if I understand correctly.

In terms of font-display and the User Agent Intervention,

 - We encourage using "font-display: swap" as a default choice for developers who care for performance

 - It's ok to experiment with the intervention for "font-display: auto"

Also, as a separate discussion, we may need a better font fallback scheme that minimize FOUT impacts?

But, what's missing ability to style fallbacks now? Now we can specify fallback fonts, line-height, and so on. But for precise style adoption, we will need font metrics character by character. Using such information doesn't sound feasible.

For a good logic to race the cache, ksakamoto@ and I are working on cache-aware timeouts for "font-display: swap, fallback, and optional". 

[Jason Pamental]

Hi Takahashi - 

Some notes inline below - thanks for the summary!

Jason

Jason Pamental | Director of Design & Product Experience

m: 401.743.4406

Fresh Tilled Soil

www.freshtilledsoil.com 

experience design for web and mobile

On Dec 2, 2015, at 3:02 AM, Takashi Toyoshima <toyo...@chromium.org> wrote:

Let me summarize discussion to confirm if I understand correctly.

In terms of font-display and the User Agent Intervention,

 - We encourage using "font-display: swap" as a default choice for developers who care for performance

 - It's ok to experiment with the intervention for "font-display: auto"

I think that what you’ve summarized above is accurate

Also, as a separate discussion, we may need a better font fallback scheme that minimize FOUT impacts?

But, what's missing ability to style fallbacks now? Now we can specify fallback fonts, line-height, and so on. But for precise style adoption, we will need font metrics character by character. Using such information doesn't sound feasible.

What’s currently usable is a class that can be targeted to trigger the CSS for the fallbacks, such as what is supplied by the web font loader (‘.wf-inactive’ injected into the HTML tag)

What would be ideal is some way solely in CSS to target styling the fallbacks so there would be no requirement for JS to make it work. 

Something like this:

body {

     font-family: “webfont name”, helvetica, sans-serif;

     font-display: fallback;

}

body[font-display=“fallback”] {

     font-family: helvetica, sans-serif;

     line-height: 1.1;

     font-size: 1.05em;

}

(I realize this may be a bit far out, but it would be great to get through this and not be reliant upon JS to complete the solution)

[Ilya Grigorik]

What's the status of CSS variables in Blink? FF seems to support them: http://caniuse.com/#search=css%20variables

view-source:http://output.jsbin.com/guzusudeva/quiet - doesn't actually work.. but, could it?

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/DD820F2E-8C7E-407C-9E78-911B26C6CE5A%40freshtilledsoil.com.

[Yoav Weiss]

Levi recently landed it (behind an experimental flag AFAICT)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADXXVKoaqL2hbTSrxyz4NBUpmALUQ9KT8gPCkFK4Ret0CLBQ7A%40mail.gmail.com.

[Takashi Toyoshima]

Thank you, Jason.

Let me send an Intent to Implement for the font-display User Agent Intervention part to blink-dev@.