3 ms·

The problem arises when you're invoking a style (like `h1` or `h2`) that by default requests a bold weight, but the `font-face` declaration only supplies a WOFF

The problem arises when you're invoking a style (like `h1` or `h2`) that by default requests a bold weight, but the `font-face` declaration only supplies a WOFF declared "font-weight: regular". In that case, the browser will try to synthesize a bold style by "smearing" the regular. One fix for this is to set heading tags to "font-weight: normal". Another fix is to supply two `font-face` declarations for the same WOFF file, covering both regular and bold, so that when the browser asks for the bold version, it just gets the same thing. (Strictly speaking, I would classify this as user error, not a browser flaw, though it's an easy mistake to make)

ryanwhitney 6y ago
People hit this so much, it's maddening. In this case, they're using Google Fonts, which already does the latter: https://fonts.googleapis.com/css?family=Poppins:400,600 https://fonts.googleapis.com/css?family=Poppins:400,600 Testing this on my own, I'm not seeing a difference between safari/chrome/firefox on macos. If there's only 400 and 600 weights present, they use the 600 for bold elements. If there's a 700, they use that. You only see faux bolding when there's nothing provided in the 600–900 range. I think the difference here might be moreso about browser font handling on windows? Though I'm still not sure how they got to the bold result at the top of the screenshot…I wouldn't expect safari to apply a faux bold when the 600 weight is there, and that sure looks like the proper 700 which apparently wasn't being called. Sidenote: I didn't know about the font-synthesis property until this. Looks like it is intended to prevent any sort of faux bolding or faux italicizing from happening. That's cool.
- andrewmcwatters 6y ago
  Perhaps it would have been better then if the web standards never allowed for defining usage of the nearest available weight. It seems to certainly have created enough confusion in the microcosm of just this thread.
deleted 6y ago
[deleted]
panabee 6y ago
Thanks for sharing this explanation! This may fix a frustrating font problem we're encountering with mobile Safari. We're also running into other font issues, such as serving Chinese fonts. Are you open to consulting? Your profile doesn't list contact information. Is it okay to send an email with more details?
ademarre 6y ago
> "Strictly speaking, I would classify this as user error, not a browser flaw, though it's an easy mistake to make" I agree, but browsers should use console warnings to report when they resort to font synthesis or weight substitution. That would go a long way to help web developers understand this problem. Similarly, console warnings to report character substitution when a needed character is not present in the font-family list would be useful. In general, I want more transparency from text rendering engines when they encounter something that may not be what a professional designer or typesetter would want. The opacity of today's engines breeds ignorance among their users (web developers).

ryanwhitney 6y ago

People hit this so much, it's maddening. In this case, they're using Google Fonts, which already does the latter: https://fonts.googleapis.com/css?family=Poppins:400,600 https://fonts.googleapis.com/css?family=Poppins:400,600 Testing this on my own, I'm not seeing a difference between safari/chrome/firefox on macos. If there's only 400 and 600 weights present, they use the 600 for bold elements. If there's a 700, they use that. You only see faux bolding when there's nothing provided in the 600–900 range. I think the difference here might be moreso about browser font handling on windows? Though I'm still not sure how they got to the bold result at the top of the screenshot…I wouldn't expect safari to apply a faux bold when the 600 weight is there, and that sure looks like the proper 700 which apparently wasn't being called. Sidenote: I didn't know about the font-synthesis property until this. Looks like it is intended to prevent any sort of faux bolding or faux italicizing from happening. That's cool.

andrewmcwatters 6y ago
Perhaps it would have been better then if the web standards never allowed for defining usage of the nearest available weight. It seems to certainly have created enough confusion in the microcosm of just this thread.

deleted 6y ago

[deleted]

panabee 6y ago

Thanks for sharing this explanation! This may fix a frustrating font problem we're encountering with mobile Safari. We're also running into other font issues, such as serving Chinese fonts. Are you open to consulting? Your profile doesn't list contact information. Is it okay to send an email with more details?

ademarre 6y ago

> "Strictly speaking, I would classify this as user error, not a browser flaw, though it's an easy mistake to make" I agree, but browsers should use console warnings to report when they resort to font synthesis or weight substitution. That would go a long way to help web developers understand this problem. Similarly, console warnings to report character substitution when a needed character is not present in the font-family list would be useful. In general, I want more transparency from text rendering engines when they encounter something that may not be what a professional designer or typesetter would want. The opacity of today's engines breeds ignorance among their users (web developers).