Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser Font Rendering Inconsistencies

blog.stephaniestimac.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Browser Font Rendering Inconsistencies

#11

Post by rado »

elondaits wrote: post #5

It's a webkit thing. Try -webkit-font-smoothing: antialiased and you'll get the version with less weight, while 'subpixel-antialiased' is the heavier one. This weight difference is more noticeable in white text against dark backgrounds. Photoshop offers several options on how to render text that show different "weight" in a similar way... they're called "Crisp", "Strong", "Smooth", etc. In particular there's a "Mac L…

No. Let the browser, macOS and the GPU do the rendering. As the below commenter said, the issue is dev error.

Re: Browser Font Rendering Inconsistencies

#12

Post by kanobo »

DiabloD3 wrote: post #9

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users. Safari enforces the OSX "thick antialiasing", causing really thick fonts. This also causes really thick fonts, unreasonably so, in normal non-web apps. The reverse, unfortunately, is true: a lot of web developers worship at the altar of Apple, and have screwed up perfectly good websites by mak…

You don't support Apple users on your website? You don't bother to fix breaking issues for any Apple device? I'm genuinely curious to know what industry you work in since that seems like a huge segment of visitors.

Re: Browser Font Rendering Inconsistencies

#13

Post by andrewmcwatters »

DiabloD3 wrote: post #9

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users. Safari enforces the OSX "thick antialiasing", causing really thick fonts. This also causes really thick fonts, unreasonably so, in normal non-web apps. The reverse, unfortunately, is true: a lot of web developers worship at the altar of Apple, and have screwed up perfectly good websites by mak…

You're describing anti-aliasing, not font-weight.

Re: Browser Font Rendering Inconsistencies

#15

Post by [deleted] »

threepio wrote: post #6

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…

[deleted]

Re: Browser Font Rendering Inconsistencies

#16

Post by aahhahahaaa »

These rendering differences also impact vertical alignment with specific fonts, which will absolutely drive you mad if you're trying to troubleshoot.

Take a look at Github's redesign in Firefox. Button and icon alignment are generally off by 1-2px everywhere because of it. Guessing they're just living with it because Firefox is down in the single-digit percentages of browsershare these days.

Re: Browser Font Rendering Inconsistencies

#17

Post by andrewmcwatters »

aahhahahaaa wrote: post #16

These rendering differences also impact vertical alignment with specific fonts, which will absolutely drive you mad if you're trying to troubleshoot. Take a look at Github's redesign in Firefox. Button and icon alignment are generally off by 1-2px everywhere because of it. Guessing they're just living with it because Firefox is down in the single-digit percentages of browsershare these days.

It's important to keep in mind that the bitmap output of various font rasterizers isn't universally the same. If you're designing websites expecting text nodes to have the exact same dimensions, you're making a critical mistake.

Re: Browser Font Rendering Inconsistencies

#18

Post by ryanwhitney »

threepio wrote: post #6

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…

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.

Re: Browser Font Rendering Inconsistencies

#19

Post by aahhahahaaa »

andrewmcwatters wrote: post #17
aahhahahaaa wrote: post #16

These rendering differences also impact vertical alignment with specific fonts, which will absolutely drive you mad if you're trying to troubleshoot. Take a look at Github's redesign in Firefox. Button and icon alignment are generally off by 1-2px everywhere because of it. Guessing they're just living with it because Firefox is down in the single-digit percentages of browsershare these days.

It's important to keep in mind that the bitmap output of various font rasterizers isn't universally the same. If you're designing websites expecting text nodes to have the exact same dimensions, you're making a critical mistake.

Yes different fonts have different dimensions, but I'm talking about the same font across different browsers. The issue is that Firefox and Webkit render the baseline of some fonts with a 1-2px difference.

It's impossible to vertically align Helvetica consistently in Firefox and Chrome without some browser-specific adjustments, but Arial works fine.

Re: Browser Font Rendering Inconsistencies

#20

Post by andrewmcwatters »

aahhahahaaa wrote: post #19
andrewmcwatters wrote: post #17

Earlier quoted context omitted.

It's important to keep in mind that the bitmap output of various font rasterizers isn't universally the same. If you're designing websites expecting text nodes to have the exact same dimensions, you're making a critical mistake.

Yes different fonts have different dimensions, but I'm talking about the same font across different browsers. The issue is that Firefox and Webkit render the baseline of some fonts with a 1-2px difference. It's impossible to vertically align Helvetica consistently in Firefox and Chrome without some browser-specific adjustments, but Arial works fine.

I am, too. The same font rendered by Core Text, FreeType, and Direct2D/DirectWrite will not have the exact same dimensions every time despite coming from the same exact file.

Say I render a font with no anti-aliasing on an embedded device, because it's marginally more expensive to do so. If I did anti-alias it, you have to account for possibly growing the bitmap size to do so. If I did, am I no longer compliant with web standards? No, because the web standards don't specify dimension requirements for text nodes from source fonts.

Further, there are multiple different types of ways to anti-alias. Should the web standards dictate how?

Post reply on HN