W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2020

Re: [csswg-drafts] Interoperable font metrics (#4792)

From: Xiaocheng Hu via GitHub <sysbot+gh@w3.org>
Date: Tue, 08 Sep 2020 19:48:27 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-689099191-1599594506-sysbot+gh@w3.org>
From the Chrome side, we'd like to +1 to `ascent-override` and `descent-override` as how @litherum proposed. In addition, we also propose:
- `line-gap-override: <percentage>` to override line gap. It works in the same way as `ascent-override` and `descent-override`
-  `advance-override: <number>` to add additional advance to characters. It's the same as how @chrishtr [proposed](https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-663264158), just renamed for better clarity

We've [prototyped](https://groups.google.com/a/chromium.org/d/msg/blink-dev/h21QrfPrkl4/ff_dZxYcCQAJ) these descriptors in Blink M86 behind a flag. The [implementation](https://chromium-review.googlesource.com/q/hashtag:%22font-metrics-override%22+(status:open%20OR%20status:merged)) isn't too complicated.


Besides interop, we are motivated by the possibility to reduce [cumulative layout shift](https://web.dev/cls/) caused by web fonts. This has also been discussed in #450.

We analyzed a set of AMP pages with CLS issues, and [found that](https://docs.google.com/document/d/1PW-5ML5hOZw7GczOargelPo6_8Zkuk2DXtgfOtJ59Eo/edit?ts=5f4ee491#bookmark=id.q0aftwc4vo6n):
- Font-caused CLS is a pretty common issue. In many cases, fonts on their own already contribute >0.1 CLS, exceeding the "good" threshold
- The new descriptors can eliminate most of the font-caused CLS when configured correctly
  - One one page, it reduced CLS from 0.93 to 0.64, while the "raw" CLS is 0.56 if we disable web fonts


One particular advantage of these descriptors is easy adoptation, especially when using 3rd party fonts from a font provider. Font providers may set the correct values of these descriptors in the stylesheets they provide (which could otherwise be pretty cumbersome for individual web authors), while web authors only need to change one line of code in their `font-family` CSS property. For example:

Font provider side:


@font-face {
  font-family: foo;
  src: url("http://example.com/foo.woff");
  font-weight: 400;

@font-face {
  font-family: fallback-to-arial;
  src: local(Arial), url("http://example.com/arial.woff");
  font-weight: 400;
  advance-override : 0.1;
  ascent-override: 60%;
  descent-override: 40%;
  line-gap-override: 0%;

Author side:


<link rel="stylesheet" href="font.provider/fonts.css">
 body {
   font-family: foo, fallback-to-arial;
   font-weight: 400;


In summary, we found this proposal straightforward enough in terms of both the spec and the implementation, and yet allows easy opt-in. We've also tried some other approaches (e.g., changing how font fallback stack works), but couldn't find one with all these advantages. So we think this should be the best way to go.

(A Google Docs version of our proposal is at https://bit.ly/39qATQ4)

GitHub Notification of comment by xiaochengh
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-689099191 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 8 September 2020 19:48:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:16 UTC