Intent to Ship: CSS font-display

[Kenji Baheux]

Contact emails

ksak...@chromium.org, kenji...@chromium.org  

Spec

https://tabatkins.github.io/specs/css-font-display/ (Tag review)

Summary

A new @font-face descriptor for controlling how a downloadable font renders before it is fully loaded.

@font-face descriptor:

Name	Value	Initial
font-display	auto | block | swap | fallback | optional	auto

Note: the API surface needed to allow first party developers to use font-display in the context of third party hosted fonts, is still being discussed and is therefore out of scope for this intent to ship.

Motivation

When using downloadable web fonts via @font-face, the user agent needs to know what to do while the web font is not available. Most web browsers have adopted some form of timeout:

Browser	Timeout triggering fallback behavior	Fallback to system font?	Swap when the web font is available?
Chrome 35+	3 seconds	yes	yes
Opera	3 seconds	yes	yes
Firefox	3 seconds[1]	yes	yes
Internet Explorer	0 seconds	yes	yes
Safari 10+[2]	3 seconds	yes	yes

[1]: simplified view of the actual behavior

[2]: since Safari 10 (used to be “no timeout, n/a, n/a”)

The 3 seconds timeout is from the point where the user agent determined that a particular web font would be needed. Synthetic example:

Font Loading API allows a developer to override some of the above behaviors, but it requires a non-trivial amount of effort and ultimately doesn’t provide sufficient hooks to cover all reasonable cases. In addition, it requires JavaScript which means a sub-optimal solution for something as critical as text rendering:

• the developer needs to either inline the loading script into their page, or else load an external library and introduce additional network latency before the fonts can be loaded, delaying text rendering.

Design/performance-conscious web developers have a good sense for the relative importance of a given web font for the intended user experience. This specification provides them the ability to control font timeout and rendering behavior. Specifically, it lets developers:

• Define the font rendering strategy when text is ready to be painted: block, or paint with fallback.

• Define the font rendering behavior once the desired font is available: rerender text with the new font, or leave it with the fallback.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/7s4-eQTAxqs/SoahsGpMAQAJ

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

Yes.

Demo link

Simple demo

1. Enable chrome://flags/#enable-experimental-web-platform-features beforehand

2. Play with DevTools’ “disable cache” as well as “network throttling” features to experience some of the behaviors.

Debuggability

Fits within the existing debuggability features for CSS APIs.

Interoperability and Compatibility Risk

Low risk.

Pluses and minuses:

+ small API footprint.

+ Mozilla has implemented CSS font-display (behing an experimental flag) + expressed interest in shipping

+ Feedback from WebKit (i.e. discussion about behavior when modifying font-display)

- No official signals from Edge.

+ Positive feedback from Travis Leithead (Microsoft; context: TAG review)

+ consensus in the CSS working group and agreement to move forward with a FPWD

- A few remaining spec issues but relatively minor, prioritized by the working group and actively tracked (marked as blocking bugs).

+ The level of interest from developers has been constantly high since inception:

• https://www.bramstein.com/writing/web-font-loading-patterns.html#custom-font-display

• http://alistapart.com/article/webfonts-on-the-prairie#section3

• https://www.viget.com/articles/the-font-face-dilemma

• http://meowni.ca/posts/web-fonts/ (+ Followup discussion on HN: "Personally, I would use font-display: optional everywhere, but that doesn’t really work anywhere yet.")

• https://speakerdeck.com/smashingmag/improving-web-fonts-performance

• https://speakerdeck.com/zachleat/the-performance-and-usability-of-font-loading

• https://speakerdeck.com/bramstein/the-consequences-of-web-fonts

• https://twitter.com/tkadlec/status/521680198585319426

• and my favorite: “CSS font-display property is going to solve all of our font loading woes” ― Patrick Hamann.

Ongoing technical constraints

None.

OWP launch tracking bug

crbug.com/530015

Entry on the feature dashboard

https://www.chromestatus.com/feature/4799947908055040  

[flo...@rivoal.net]

Hi,

This is a very interesting feature and I'm happy to see progress on it, but I think this intent to ship misstates the maturity of the specification.

You're quoting the CSSWG's IRC (https://log.csswg.org/irc.w3.org/css/2017-01-12/#e760513) to say it is prioritized by the working group, but that discussion is about a related but different specification: The one that the CSSWG wants to prioritize getting to CR is https://drafts.csswg.org/css-font-loading/ which is different from the https://tabatkins.github.io/specs/css-font-display/ spec discussed here. font-display has been discussed in the WG in the past, and is also (as can be see higher up in that IRC log) something the CSSWG wants to get going, but it is only about to become an official draft in the WG, not about to reach CR.

Even though the spec has been presented to the CSSWG in the past, since it hadn't been taken on as a work item yet, I would be careful about describing the open issues as being only a few "remaining" ones. It is not clear that broad/deep review of that spec has actually happened yet.

I would recommend prioritizing making it into an actual CSSWG spec, and getting some additional review and issue resolution before feeling too confident about the document being stable and the future interop/compat risks being low. Since it is a very focused specification, hopefully that can happen fast, but I'd recommend starting there.

—Florian

[Emil A Eklund]

On Wed, Jan 18, 2017 at 7:41 PM, <flo...@rivoal.net> wrote:

Hi,

This is a very interesting feature and I'm happy to see progress on it, but I think this intent to ship misstates the maturity of the specification.

You're quoting the CSSWG's IRC (https://log.csswg.org/irc.w3.org/css/2017-01-12/#e760513) to say it is prioritized by the working group, but that discussion is about a related but different specification: The one that the CSSWG wants to prioritize getting to CR is https://drafts.csswg.org/css-font-loading/ which is different from the https://tabatkins.github.io/specs/css-font-display/ spec discussed here. font-display has been discussed in the WG in the past, and is also (as can be see higher up in that IRC log) something the CSSWG wants to get going, but it is only about to become an official draft in the WG, not about to reach CR.

The log clearly indicates that we were talking about css-font-display and even links to the draft (https://tabatkins.github.io/specs/css-font-display/). We resolved to publish a first public working draft for font-display as indicated in the log, at least that is how I remember it.

There was discussion about the overlap between font-loading and font-display but the consensus was to keep them separate for the sake of moving quickly with the eventual plan to merge them once in CR. 

Thanks

--

Emil

[fri...@gmail.com]

On Friday, January 20, 2017 at 3:18:33 AM UTC+9, Emil A Eklund wrote:

On Wed, Jan 18, 2017 at 7:41 PM, <flo...@rivoal.net> wrote:

Hi,

This is a very interesting feature and I'm happy to see progress on it, but I think this intent to ship misstates the maturity of the specification.

You're quoting the CSSWG's IRC (https://log.csswg.org/irc.w3.org/css/2017-01-12/#e760513) to say it is prioritized by the working group, but that discussion is about a related but different specification: The one that the CSSWG wants to prioritize getting to CR is https://drafts.csswg.org/css-font-loading/ which is different from the https://tabatkins.github.io/specs/css-font-display/ spec discussed here. font-display has been discussed in the WG in the past, and is also (as can be see higher up in that IRC log) something the CSSWG wants to get going, but it is only about to become an official draft in the WG, not about to reach CR.

The log clearly indicates that we were talking about css-font-display and even links to the draft (https://tabatkins.github.io/specs/css-font-display/). We resolved to publish a first public working draft for font-display as indicated in the log, at least that is how I remember it.

That's right, I was not trying to disagree with that. We were talking about font-display, and we did agree to publish a FPWD. I am not disputing the part of the original mail where you stated "consensus in the CSS working group and agreement to move forward with a FPWD". That is absolutely in line with what was said at the meeting.

What I was responding to was the separate statement that there were "a few remaining spec issues but relatively minor, prioritized by the working group", where the link points to a statement in IRC saying "Deal with issues on font-loading so it can go to cr". That is a later part of the conversation, and that part is about fond-loading, not font-display.

So yes, the proposal has broad support in the WG, and has a decision to go to FPWD, but it does not have a short list of issues prioritized by the WG in preparation to go to CR.

—Florian

[Kenji Baheux]

Hi Florian,

I want to apologize: I reread the IRC log and can confirm that I was confused.

The resolution about the spec issues was regarding font-loading, not font-display.

We currently have 6 issues: 2 trivial editorial matters, and 4 issues with tentative consensus.

We would love to hear feedback from the CSSWG on these 4 issues and the spec in general.

--
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.

[fri...@gmail.com]

On Wednesday, January 25, 2017 at 1:50:31 PM UTC+9, Kenji Baheux wrote:

Hi Florian,

I want to apologize: I reread the IRC log and can confirm that I was confused.

The resolution about the spec issues was regarding font-loading, not font-display.

No problem, it was a subtle and easy to miss.
 

We currently have 6 issues: 2 trivial editorial matters, and 4 issues with tentative consensus.

We would love to hear feedback from the CSSWG on these 4 issues and the spec in general.

Absolutely, that'd be good. Doing the FPWD publication and migrating the issues to the csswg repo will probably help, and if that's not enough putting them on the group's teleconf agenda should do the rest: as people review these particular issues, they'll need to read the rest of the spec to make sense of them.

—Florian

 

[Rick Byers]

A related concern: generally we avoid shipping APIs based solely on specs in someone's personal GitHub.  Eg. this can limit the ability of some implementors to provide technical feedback due to the lack of any IPR commitments, so we can't be confident that there aren't technical objections which haven't yet been raised.

To ship this I'd personally prefer (other owners may feel differently) that we either:

1. Move it into the csswg-drafts repo, get it published as a FPWD and work with CSSWG folks to get the spec in a state that the WG is comfortable with us shipping ASAP.  OR
   
   
2. Get support from one of the other implementors to incubate this via WICG and move the spec / open issues to a new repo there.  Given the high developer demand and support from other vendors, with a bit of effort tying up loose ends and barring any outstanding technical concerns that would pose compat risk, I'd expect that this could reasonably be ready to ship in M58 (i.e. on in trunk in the next 5 weeks)
   

Tab, Kenji: which path do you want to follow?

[fri...@gmail.com]

On Thursday, January 26, 2017 at 12:07:10 AM UTC+9, Rick Byers wrote:

A related concern: generally we avoid shipping APIs based solely on specs in someone's personal GitHub.  Eg. this can limit the ability of some implementors to provide technical feedback due to the lack of any IPR commitments, so we can't be confident that there aren't technical objections which haven't yet been raised.

To ship this I'd personally prefer (other owners may feel differently) that we either:

1. Move it into the csswg-drafts repo, get it published as a FPWD and work with CSSWG folks to get the spec in a state that the WG is comfortable with us shipping ASAP.  OR
   

You can of course do what you want, but given that this was just (2 weeks ago) requested by the CSSWG to go FPWD, and that there was interest from Mozilla to work on it there (because they have it implemented and they want to ship too), I'd expect very little friction there, and would suggest that that is the preferred venue.

—Florian

[Yoav Weiss]

(with WICG co-chair hat on)

Since this spec was already throughly discussed in the CSSWG, it makes sense IMO to move it directly there (assuming the CSSWG is interested in taking on this work, and unless spec authors prefer otherwise).

[Tab Atkins]

On Wed, Jan 25, 2017 at 7:06 AM, Rick Byers <rby...@chromium.org> wrote:
> A related concern: generally we avoid shipping APIs based solely on specs in
> someone's personal GitHub. Eg. this can limit the ability of some
> implementors to provide technical feedback due to the lack of any IPR
> commitments, so we can't be confident that there aren't technical objections
> which haven't yet been raised.
>
> To ship this I'd personally prefer (other owners may feel differently) that
> we either:
>
> Move it into the csswg-drafts repo, get it published as a FPWD and work with
> CSSWG folks to get the spec in a state that the WG is comfortable with us
> shipping ASAP. OR

That's what we're doing right now (when I take the time to start it),
per resolution at the last f2f.

~TJ

[Kenji Baheux]

Update: CSS font-display has just been incorporated into the FWPD for CSS fonts-4.

[Philip Jägenstedt]

Does that mean that this intent is "live" again, should API owners take a look?

[Kenji Baheux]

I believe that the candidate(?) FPWD is on the agenda for the CSS F2F happening next week.

So, let's revisit then.

[Kenji Baheux]

The FPWD has been reviewed and approved.

This intent can be reviewed again.

[Philip Jägenstedt]

Sorry for the lack of action here, once things fall off the weekly batch there are apparently no guarantees :/

LGTM1 % nits, the feature itself is pretty small and there's apparently quite a bit of interesting from developers. The nits:

An explainer was requested in https://github.com/w3ctag/design-reviews/issues/71 but doesn't exist. Perhaps some other suggestions also fell between the cracks when the issue was closed.

Since this intent was sent, the question of web-platform-tests was added to the template. It looks like there aren't any tests in wpt, but two in LayoutTests/http/tests/webfont/ that should be easy enough to convert and upstream. Is this something that can be prioritized together with the shipping? (If it's unreasonably difficult, then please file a follow-up bug and mark it as blocking this bug.)

[Chris Harrelson]

LGMT2

--

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+unsubscribe@chromium.org.

[Rick Byers]

LGTM3

So this is a case where we delayed shipping for ~3 months to block on the CSSWG process.  I'm curious, to what extent has the spec for font-display improved during that time (i.e. what did we buy in exchange for the delay)?  If there's nothing that's fine (doesn't mean it's not a good trade-off on average), but if there was some real meaningful change then it's a signal that such delay may be worth the cost.

Also from a quick scan of the IRC log I don't see explicit discussion saying Chrome is planning on shipping font-display.  If there hasn't already, can you somehow make sure the WG is aware that we're shipping an API here that hasn't yet reach CR?

[Florian Rivoal]

On May 12, 2017, at 03:10, Rick Byers <rby...@chromium.org> wrote:

So this is a case where we delayed shipping for ~3 months to block on the CSSWG process.

I do not think this is a fair characterization, and as you try and take into account what works well and what doesn't to tune your process, I think it's worth looking at what actually happened so that we can draw the right conclusions.

Google first proposed the idea in April 2015 [1]. During that very same teleconf, the working group agreed to make this into CSSWG's Editors Draft. Google never follow up on that, and did not submit the document as an editor's draft.

The spec was further discussed in May 2015[2][3], leading to useful feedback, that was incorporated in the spec, which was still hosted in a personal repo.

Then it wasn't brought up by Google for about 2 years, although there were a handful of discussions involving that spec.

Then Mozilla, wanting to ship it, suggested that it really should become a CSSWG FPWD, which was immediately[4] approved.

Then nothing happened for 3 months.

Then Mozilla insisted [5] that we ought to do something, which could be either the font-display FPWD, or including it in css-fonts level 4.

3 days later, Apple included it in css-fonts level 4 [6], and 4 days after that [7], the spec (which includes many more things) was approved for FPWD.

In the end, it's a useful spec, thanks for initiating it, and it is good that it is now a FPWD, and it is good that multiple browsers are implementing. And yes, it is unfortunate that this has been delayed. However I don't think you should put the responsibility for the delay on the CSSWG when Google was the one not following up, and when it was incorporated in a spec and approved as FPWD within a week of other CSSWG members taking the matter in their own hands.

Note that I don't particularly care to put the blame on any individual at Google, since I know that each of you has way too much on their plate, and that prioritization means that some times some things fall behind. But putting the responsibility for the delay on the CSSWG will lead you to incorrect conclusions about what works and what doesn't in the process.

Had this been actually published as an ED when the CSSWG first approved doing so, it could probably have been a FPWD by summer 2015, and would probably be in CR by now, or maybe even further (dare I say REC?) depending tests contributions and pass rates by Chrome and Firefox done as part of your respective implementations.

I'm curious, to what extent has the spec for font-display improved during that time (i.e. what did we buy in exchange for the delay)?

The 6 open issues tracked in the original private repo had not yet been submitted to the CSSWG for discussion by Google or anyone until today. Not in github, nor in a conf call, nor on the mailing list, nor at the recent F2F. So no feedback yet, unfortunately. I just reported all these issues to the CSSWG[8] and put them on the agenda, so that we can get to them soon.

—Florian

[1] https://lists.w3.org/Archives/Public/www-style/2015Apr/0143.html

[2] https://lists.w3.org/Archives/Public/www-style/2015May/0315.html

[3] https://lists.w3.org/Archives/Public/www-style/2015Jun/0245.html

[4] https://lists.w3.org/Archives/Public/www-style/2017Feb/0057.html

[5] https://github.com/w3c/csswg-drafts/issues/1201

[6] https://github.com/w3c/csswg-drafts/issues/1201#event-1042912707

[7] https://log.csswg.org/irc.w3.org/css/2017-04-18/#e796498

[8] https://github.com/w3c/csswg-drafts/issues/1357

[Rick Byers]

Thanks for the detailed timeline Florian, that's very helpful!