Csswg-drafts: Interoperable font metrics via explicit font metrics overrides

[litherum]

Migrated from https://github.com/w3c/csswg-drafts/issues/2228#issuecomment-380762748

In font files, there exist at least three different ascent/descent values:

• ascender and descender from the hhea table
• sTypoAscender and sTypoDescender from the OS/2 table
• usWinAscent and usWinDescent from the OS/2 table
• maybe others???

Different browsers / OSes use different values. In fact, some even use values that are not present in the font file at all. This leads to content being laid out differently on different browsers / OSes. https://github.com/w3c/csswg-drafts/issues/2228 is an example of one. There have been others.

There have been efforts to try to introduce "interoperable" metrics into CSS (https://github.com/w3c/csswg-drafts/issues/3978 is one, https://github.com/w3c/csswg-drafts/issues/938 is related, there are a few others too), to force browsers to agree on which metrics they use. Many of the existing proposals so far have some downsides:

• They require browsers to parse font files, rather than relying on special-purpose font parsing libraries (such as CoreText). A tenet of the web platform is that browsers should be able to delegate responsibility to helper libraries.
• They cause all text to be laid out differently, across every website in the entire web. Such a massive change is too scary from a product development standpoint.
• Any approach which is opt-in for specific cases causes text metrics to not match throughout the page. This can lead to inconsistent spacing and poor typography / webpage design.

However, interoperable font metrics _are_ desirable for many page authors. Here's a compromise proposal that (I believe) solves all the above problems:

What if we add a new descriptor into @font-face to let the CSS author override the metrics of the font? Something like this:

@font-face {
    font-family: "WebFont";
    src: ...;
    ascent-override: 80%;
    descent-override: 20%;
}

Those percentage values are resolved by multiplying by the font size (em box). Negative values are illegal. The browser doesn't have to parse any font files, all browsers will agree on the resolved value, and all text in all situations drawn with that font will use these values.

There's already precedent for this: the font-feature-values and font-variation-values descriptors in @font-face overrides the defaults present in the font file.

[kojiishi]

Thank you for writing this up! /cc @kojiishi @drott

[emilio]

/cc @jfkthame

[Crissov]

The downside of any solution that relies on @font-face is that it does not work for local fonts unless authors reference them with local(), which they hardly do in my experience. Please correct me if Iʼm wrong.

[faceless2]

(other proposals) cause all text to be laid out differently, across every website in the entire web. Such a massive change is too scary from a product development standpoint.

I suspect not applying this to local (or even generic) fonts might be entirely intentional.

It's a good compromise idea - I still think we need leading-override too, as OpenType has at least hhea.LineGap and OS/2.sTypoLineGap defining this.

There are other metrics to consider. Both x-height and cap-height are both in the OpenType PCLT table, and there are the baselines too (in the BASE table). All of these are stored only in one place in the font, so if this issue is purely about removing ambiguity and not about overriding metrics, then I'm not sure whether overriding these is important.

[tobireif]

I really appreciate any and all efforts that have the goal of fixing https://github.com/w3c/csswg-drafts/issues/2228 .

This here ticket wouldn't solve my use-case in a way that's convenient enough - I'd first have to figure out which percentage values to fill in.

A good solution would allow me (and other web developers) to ensure that the described cross-OS-differences won't happen (in modern standards-based browsers) - in a convenient and quick way, eg glyph-positioning: glyph-bounding-box (the exact names are up to you / the W3C 😀)

Chrome on MacOS:

Chrome on Windows:

[tobireif]

They cause all text to be laid out differently, across every website in the entire web. Such a massive
change is too scary from a product development standpoint.

Any solution should be opt-in.

Any approach which is opt-in for specific cases causes text metrics to not match throughout the
page. This can lead to inconsistent spacing and poor typography / webpage design.

That's the responsibility of the web developer. They can apply it to the whole page or only to portions of it - it's up to them. I think that typically the property would be used for eg a large heading and that's it - the rest of the page would be smaller text (where the issue is eg negligible and which might not use the same font as the heading). In any case - it's the responsibility of the web developer to ensure consistent spacing and good typography etc. (That's the exact reason why I had posted #2228 😀 because I was trying to do just that.)

[tobireif]

If your proposal will the the only/last offer by the W3C for solving the issue(s) described in #2228 , then I guess I should accept it (towards then closing that ticket) - if it solves the issue(s) described in #2228 completely, and although it requires a bit more work than I had wished for.

[khaledhosny]

One can already override font provided line spacing with CSS line-height and it does not require any font parsing either, what additional benefit one would get from the proposed @font-face overrides?

[jfkthame]

Setting line-height is not sufficent -- within a given line-height, where does the baseline of the text go? This depends on the relative ascent & descent metrics.

[faceless2]

Yes, you can set a specific line-height every time you use that font and get consistent cross-browser results for line-spacing.

But it seems if you're overriding ascender/descender, on which the default value of line-height depends, you might also want to set the default line-height (edit: by setting the leading) as well. It's not necessary, but it will save you specifying line-height everywhere you use the font. If the stylesheet defining the font is being imported by someone not familiar with the modified metrics, this is probably quite important.

[jfkthame]

It seems to me we could reasonably use CSS properties (not just font-face descriptors) here: something like font-ascent, font-descent and font-linegap, all with initial values of auto (meaning the browser derives metrics from the font or from system APIs or whatever), but with authors having the possibility to use percentages (to be resolved based on em size) instead.

normal line height would then be based on the used values of these metrics.

Then it might also be useful to have these as font-face descriptors, which would allow webfonts to override the result of auto, while leaving system fonts to do their normal thing. So authors could choose to take control just for a specific web font (using the descriptors), or to override the browser's auto behavior for arbitrary content in any font (using the properties). All this would be opt-in for authors, so there's no risk to existing content.

An author could then choose to do something like

:root { font-ascent: 80%; font-descent: 20%; font-linegap: 10%; }

and expect to get consistent line-spacing behavior across browsers and platforms -- with the understanding that the result may not be the same as any given browser currently gives by default, but it's entirely under their control.

I suppose the metrics properties (not descriptors) should probably accept absolute lengths, calc expressions, etc. for completeness, although em-based percentages would usually be the most sensible thing to use.

The final piece would be to add a from-font value to each of these properties (distinct from auto), and define exactly what it means in terms of metrics from an OpenType font file; I would suggest the sTypo* values would be the appropriate choice. (This might require browsers to peek into font files, if system APIs don't provide the required metrics, so may be less convenient to implement.)

[tobireif]

@khaledhosny wrote:

One can already override font provided line spacing with CSS line-height

line-height:normal does not help, see https://github.com/w3c/csswg-drafts/issues/2228#issuecomment-366310641

Chrome on MacOS:

Chrome on Windows:

line-height: 1 does not help either, see https://github.com/w3c/csswg-drafts/issues/2228#issuecomment-504767148

@faceless2 wrote:

Yes, you can set a specific line-height every time you use that font and get consistent
cross-browser results for line-spacing.

The issue is not only about line-spacing 😀The issue is shown in the above screenshots. When it appears it appears even for a single line or word, on one OS vs another (more at #2228 ).

@jfkthame wrote:

Setting line-height is not sufficent

True!

[litherum]

@jfkthame

The final piece would be to add a from-font value to each of these properties (distinct from auto), and define exactly what it means in terms of metrics from an OpenType font file

I believe this fails the “browsers having to parse font files” test.

[litherum]

@jfkthame

It seems to me we could reasonably use CSS properties (not just font-face descriptors) here

Just to make sure I understand, would these properties apply to the block container? Non-inherited? And would they override any/all ascent and descent values for every inline descendent?

[jfkthame]

The final piece would be to add a from-font value to each of these properties (distinct from auto), and define exactly what it means in terms of metrics from an OpenType font file

I believe this fails the “browsers having to parse font files” test.

Yes - I figured you probably wouldn't be keen on this value (though we have from-font for a couple of the text-decoration properties; doesn't that require browsers to parse font files, too?) Anyhow, I see it as an optional part of the overall suggestion; I think it'd be logical to include a from-font value, but it's not required in order for the properties to be useful.

Just to make sure I understand, would these properties apply to the block container? Non-inherited? And would they override any/all ascent and descent values for every inline descendent?

I haven't really thought about how inheritance etc ought to work... the suggestion that an author might write

:root { font-ascent: 80%; font-descent: 20%; font-linegap: 10%; }

was based on the idea that these properties would inherit (as percentages, to be resolved for each element against its used font-size), but maybe that's not the right approach.

Just throwing ideas out, really, and happy to hear ideas on how it would best work (or why it wouldn't).

[drott]

If we allow custom overrides, values, percentages, etc. I'd prefer to not have those placed as descriptors in @font-face but rather as new properties. I'd also be very supportive of a from-font value. I'd be even more supportive of not allowing custom value overrides, but only some form of keyword to indicate: "use sTypo* only" - in which case I'd be okay with having that as a descriptor in the @font-face header.

Background for not placing overrides in @font-face are issues https://github.com/w3c/csswg-drafts/issues/2531 as well as my proposal in https://github.com/w3c/csswg-drafts/issues/4358. Placing overrides in @font-face is not supported in Chrome currently and architecturally difficult. We removed font-variant in the spec as an override, and I would be happy if we could remove other overrides there as well.

@litherum if I am not mistaken in skimming through the code, WebKit already has code for parsing several OpenType fields manually (for math table, vertical layout metrics), as well as even for sTypoMetrics (but this may not be used when running on Mac OS). I do understand your preference to have CoreText handle metrics parsing, but wouldn't this be an acceptable case of accessing this data to enable a from-font keyword? Or alternatively, since you work closely with your CoreText colleagues, couldn't they expose the sTypo* metrics for you?

[fantasai]

@jfkthame I would prefer to discuss properties (rather than @font-face descriptors) in a separate issue, as it has rather different implications and considerations than an @font-face descriptor. Also for the record, I don't think it's a good idea. Where to place the ascent/descent metrics is very font-dependent, and applying numbers fine-tuned to one font to another is liable to cause overlapping text. As for handling line-gaps and switching out how we measure the height of text, that's a css-inline issue, not a font issue, and is being handled there. [ in reply to https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-588341590 ]

[chrishtr]

There is another use case that would I think be solved by the proposal in this issue: matching fallback font metrics to emulate a web font, so as to minimize layout shift during page load. See here for one example; this can currently be combined with font face observation script libraries to dynamically update styles to remove the overrides. If we also add a descriptor such as:

letter-spacing-override: 0.1

(which would introduce a 0.1em extra spacing between letters) then we can also solve that use case, and avoid the use of these scripts. Using these scripts effectively is quite difficult since the script would have to be loaded extremely early in the page lifecycle. For that reason I think most sites don't use these libraries, even though they might improve page load UX.

To use these overrides on a fallback font-family, the site would have to wrap it in an @font-face rather than a built-in font.

[litherum]

See: https://github.com/w3c/csswg-drafts/issues/2228#issuecomment-631657902 and https://github.com/w3c/csswg-drafts/issues/5485

[litherum]

@chrishtr There's a issue https://github.com/w3c/csswg-drafts/issues/450 trying to solve this use case from another angle.

[xiaochengh]

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, just renamed for better clarity

We've prototyped these descriptors in Blink M86 behind a flag. The implementation isn't too complicated.

---

Besides interop, we are motivated by the possibility to reduce cumulative layout shift (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:

• 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.provider/fonts.css:

@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:

main.html:

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

---

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)

[tobireif]

@xiaochengh Will this also fix #2228?

[chrishtr]

In addition to issue #450, there is issue #126, which is also about fallback fonts causing layout jumping / Cumulative Layout Shift (CLS) impact.

@tobireif : yes I think it will solve issue #2228 as well.

[litherum]

line-gap-override: <percentage> makes sense to me.

I think advance-override needs some more time to bake, since it isn't actually adjusting font metrics - it's adjusting the letter-spacing CSS property. The CSS spec already today says that letter-spacing isn't just adding a constant to the advance of each glyph, but instead understands where inline elements end and avoids adding extra space at the end of runs. The behavior specified in the spec today is desirable - simply adding a constant to each glyphs' advance leads to bad typography. Correctly implementing this more complicated spacing algorithm would be tricky to do if one font in the font-family list has advance-override set to one thing but another one has it set to another thing.

[xiaochengh]

Thanks for the feedback!

Regarding advance-override: Though it looks very similar to the letter-spacing CSS property, they are actually for different purposes. letter-spacing is for good typography, while advance-override is proposed mainly to reduce CLS when switching from a local fallback font to a web font. Therefore, they should work in different ways, and issues with letter-spacing (like #1518) do not necessarily apply here.

For the goal of reducing CLS, we want to match the text widths of the fallback font and web font, which requires advance-override to adjust the advance of each glyph†, not just the spacing between glyphs (so, we do want extra space at the end of runs). In this way, the width difference between fallback font and web font can be minimized. In the best case, if we are using monospace, we can even perfectly match the widths and get 0 CLS by setting advance-override: x - y, where x and y are the character widths of the web font and fallback, respectively; If we override the spacing between glyphs only, the adjusted with is always off by x - y.

Below are some examples where overriding the spacing leads to larger CLS when switching font:

• In a table where the column widths depend on text widths. We want to match the text width as much as possible to reduce the horizontal shifting of the cells
• In a line with multiple fonts, e.g. in example 23 in the spec, where we want spacing applied to the 2nd "b"
• In a line with mixed text and non-text inline elements
• When line wraps, the advance of the last character (very slightly) affects the total width and therefore affects where line breaks

Btw, this is also the reason we renamed it to advance-override: to emphasize what it actually overrides.

† At a more detailed level (illustration), advance = left side bearing (lsb) + glyph width + right side bearing (rsb). To match text width, advance-override should adjust lsb and rsb of every glyph, which is essentially adjusting the advance of every glyph.

[fantasai]

Agree with @litherum wrt concerns about advance-override.

Wanted to note that we have also talked about metrics for superscript/subscript, so that would be something like:

• superscript-shift-override & subscript-shift-override
• superscript-size-override & subscript-size-override

[tabatkins]

Hm, advance-override would only work reasonably for monospace fonts, right? On a variable-width font, it would set the advance for all characters to the override value, effectively turning it into monospace, which seems bad.

(Solving the "fallback screws up your monospace grid" problem is important on its own, of course, but being able to solve the "tweak a fallback font so that it ends up very close to the primary font" for variable-widths would also be great.)

[tabatkins]

But I suppose the variable-width case does need something more like letter-spacing, as Myles indicates. So it'll need to be something different anyway.

But yeah, for the monospace case we definitely do not want to act like letter-spacing, we absolutely want to affect the actual advance, so this seems like the right approach for monospace fonts. Just need to make sure the name isn't going to be confusing with whatever we do for variable-width things later. (I think it's probably okay, as the name will probably invoke letter-spacing somehow.)

[faceless2]

Not directly relating to the proposed descriptors, but the general approach opens the door for a lot of other descriptors which might be useful, not least being able to override (or even invent) baselines positions, i.e. being able to set the a "hebrew-top" baseline or other script-specific baselines as suggested in https://github.com/w3c/csswg-drafts/issues/5244

[css-meeting-bot]

The CSS Working Group just discussed Interoperable font metrics, and agreed to the following:

• RESOLVED: Add ascent, descent, and linegap override as fontface descriptors that take %

The full IRC log of that discussion

<dael> Topic: Interoperable font metrics

<dael> github: https://github.com/w3c/csswg-drafts/issues/4792

<dael> myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict.

<dael> myles: Most egregious is there are 3 different asc and desc metrics in open type font files. All different numbers. Some browsers use some, others use others.

<dael> myles: Some use metrics not even in the file. It's the wild west

<dael> myles: This is an interesting problem b/c all text is rendered with whatever metrics the browser happens to use. Any solution that's browser Y should switch is a pretty scary change. It changes all text on the web. So I think it's nto a good solution

<dael> myles: Looked for better. A few design principles I wanted to abide by. All text should not be changes. Browsers should not have to parse font files themselves, they should be able to delegate to lower level libraries.

<dael> myles: Last is that we don't want to have different metrics for some properties than others. If we do that you end up with inconsistent typography and poor design

<dael> myles: Given those requirements I think best way to solve is for CSS authors in CSS to override metrics inside font file. The mechanism for doing this is a new descriptor or set of descriptors in font-face block. A css author can override the font file metrics and say please instead use 80%em for asc.

<dael> myles: Satisfies constraints and gives consistency if authors use this. And if browser doesn't understand it falls back to font file.

<chris> q+ to wonder if Chrome is proposing or arguing against a descriptor

<xiaochengh> q+

<dael> myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts.

<Rossen_> q?

<Rossen_> q+ TabAtkins

<Rossen_> ack chris

<Zakim> chris, you wanted to wonder if Chrome is proposing or arguing against a descriptor

<dael> chris: Reading thread I'm puzzled. I see people from chrome saying they don't want descriptors and existing ones should be removed. See others from chrome proposing descriptors. I appreciate opinions can change but would like to know their current opinion.

<Rossen_> ack xiaochengh

<dael> xiaochengh: From chrome side we do want descriptors. Earlier comment opposing was mostly from impl side. We've prototyped the descriptors behind a flag so impl isn't an issue.

<dael> chris: Does that only apply to these descriptors or also to previous descriptors?

<dael> chrishtr: Which did you have in mind?

<myles> q+ to talk about descriptors vs properties

<dael> chris: Dominic pointed to other issues saying removed font-varient and would like to remove other overrides. Basically, are you now happy with these or still look at removing?

<dael> xiaochengh: Others aren't covered, should look independently

<faceless2> q+

<dael> chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles

<TabAtkins> q-

<Rossen_> ack myles

<Zakim> myles, you wanted to talk about descriptors vs properties

<fantasai> strong +1 to using descriptors, strong -1 to using properties for this

<faceless2> q-

<dael> myles: Talk directly about descriptor vs property. Descriptors are a direct natural fit to way metrics are handled by browsers. When you use a font face you have a font associated. Way to impl this is when you pull out metrics remove that and slot in from the rule.

<chris> I agree that descriptors seem like a good fit here, beter than propoerties as Myles said. I just didn't want a solution tht had been argued against in the past.

<florian> agreed, descriptors are a much better fit indeed.

<dael> myles: If we wanted to move to property not against but tricky problems like how does font fallback work if you have nested element with different font family. Multiplier on font size? A bunch of questions. If we can answer that's fine but descriptor approach means we don't have to.

<dael> chris: Agree they're a better fit

<Rossen_> q?

<TabAtkins> q+

<dael> myles: I can also talk about the 2 additional descriptors from xiaochengh. line gap amkes a lot of sense. Advanced override I'm not against but unanswered questions about how interacts with letter-spacing. Letter-spacing is not a simple property.

<dael> myles: Would be unfortunate if we had 2 ways of effecting letter-spacing and they worked differently. So there's still some design work for that one. line-gap-override makes sense

<xiaochengh> q+

<dael> TabAtkins: There is 2 separate mechnically things to do that are letter-sapcing like. Advance-override solves making sure monospace isn't screwed up with fallback. You want to effect advance of a letter to make sure they have exact width of primary font.

<florian> q+

<Rossen_> ack TabAtkins

<dael> TabAtkins: Nothing to do with variable width fonts. That wants to be more like letter-spacing so you don't have awkward spaces. Have to be different and separate. advance-override which is make monospace work with fallback is straightforward

<dael> myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case

<dael> TabAtkins: Would for monospace

<dael> myles: Not for font fallback

<dael> TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name

<Rossen_> ack xiaochengh

<dael> xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor.

<dael> xiaochengh: At this moment problem with variable width font is value of this descriptor has to be tried manually. Agree there's a design issue but we do want this descriptor

<dael> myles: We can open up a few issues

<dael> fantasai: I strongly want advance-override to be in a separate issue. Needs to be discussed in more detail. Monospace case also has a bunch of considerations. Not sure why adding a fixed value is right because ratio change.s It's a crude fixup.

<chris> Flashback to 1997 - all the widths in a descriptor https://www.w3.org/TR/WD-font-970721#widths :)

<myles> +1 to fantasai re:advance-override

<florian> +1

<dael> fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics

<jfkthame> +1 here too

<fantasai> s/change.s/changes depending on the exact font/

<fantasai> s/ratio/ratio of advance widths for different letters/

<dael> chrishtr: Agree we should split advance-override. I think this is appropriate to 2nd use case from xiaochengh more than the original one brought by myles. Split and continue to discuss

<florian> q-

<Rossen_> ack florian

<Rossen_> ack fantasai

<dael> Rossen_: Other comments? If not are we coming to resolution?

<dael> fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors

<dael> myles: and they take %s

<dael> Rossen_: Objections?

<dael> chrishtr: sgtm

<dael> RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %

<fantasai> s/lanegap/line-gap/

<dael> fantasai: While we're on topic should we add the super and subscript variants

<faceless2> +1 from me on @fantasais additions

<dael> chrishtr: Sound interesting, want to look more

<dael> fantasai: Briefly, font has metrics on amount to shipt up/down for super/subscript and says what size as function of font size. If font provides a glyph it's supposed to provide ones that match. If you don't have glyph UA can synth by resizing. IN order to get that to match you need metrics and a lot of fonts don't have

<dael> chrishtr: Is there difference between OS and browsers?

<dael> fantasai: No, font metrics are frequently wrong

<fantasai> chrishtr, see example in https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop

<dael> Rossen_: This is very much related but I would prefer we open a new issue where more thought can be given. fantasai can you open that?

<dael> fantasai: Yep

[tabatkins]

Hm, advance-override would only work reasonably for monospace fonts, right? On a variable-width font, it would set the advance for all characters to the override value, effectively turning it into monospace, which seems bad.

Ah, I was misled by the name; as currently specified, it adds a value to the existing advance of each character. So to get a fallback monospace to match the primary monospace, you set it to the difference in their two widths. The name should be changed, or the meaning should match the name. ^_^

This would then work for variable-width fonts, but as Elika said in the call and Myles suggested in earlier comments, handling variable-width well probably wants a smarter solution: l and w probably want different amounts of advance adjustment; it probably wants to act like letter-spacing and not add space at the end of a span; etc.

[tobireif]

Please ensure that implementers will be required to make sure that your new CSS addition will be a reliable a way for web developers of working around the issue(s) described in #2228 .
Also see for example https://bugs.chromium.org/p/chromium/issues/detail?id=1116349 and https://bugs.chromium.org/p/chromium/issues/detail?id=800693 .

[xiaochengh]

I just put up #5521 to add ascent-override, descent-override and line-gap-override to the spec. Could anyone review it?

[svgeesus]

I just put up #5521 to add ascent-override, descent-override and line-gap-override to the spec. Could anyone review it?

The PR was reviewed and has been merged. You can see it in the spec here.

Well, now we need WPT tests :)

[xiaochengh]

I guess we also need to modify the JS FontFace interface to include these new descriptors?

https://drafts.csswg.org/css-font-loading-3/#fontface-interface

[svgeesus]

I guess we also need to modify the JS FontFace interface to include these new descriptors?

Yes, indeed

[litherum]

I guess we also need to modify the JS FontFace interface to include these new descriptors?

Yes, indeed

Does this need a separate WG resolution? I hope not.

[astearns]

No additional resolution needed. It follows directly from the existing resolution.

[xiaochengh]

Could anyone review #5538? Just a trivial patch adding attributes to FontFace for the overrides.

[yisibl]

How to solve the punctuation marks, I tried to use unicode-range to cover the punctuation marks individually, and found that line-gap-override will take effect for the entire font.

Demo: https://codepen.io/yisi/pen/xxVmzOM

advance-override can only control the right width of characters. Is this a bug in Chrome?

@font-face {
  font-family: 'STSongti-SC-Regular-punctuation';
  advance-override: -0.4; 
  src: local(STSongti-SC-Regular);
  unicode-range: U+b7;
}

[xiaochengh]

@yisibl Thanks for trying the prototype 😄

• I'm not sure what you mean by "line-gap-override will take effect for the entire font". If you believe it's a Chrome bug, could you file a bug at crbug.com instead?
• We haven't reached any resolution on advance-override should work yet, so Chrome's current behavior is just arbitrary and can be changed at any time. Please use #5533 if you want to join the spec discussion