Hacker News Reader

Comment by threepio | Hacker News Reader

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)

View on HN

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

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

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.

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.

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?

Reply on news.ycombinator.com