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

21–30 of 52 posts

Re: Browser Font Rendering Inconsistencies

#21

Post by DiabloD3 »

kanobo wrote: post #12
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.

Any websites that I work on, which I don't often anymore, use standards. If its broken in Safari, then Safari needs to support the agreed upon W3C standards. I don't personally do weird cutting edge stuff, its stuff generally that's been supported in Firefox and Chrome stable for years. Safari must implement these, or be discontinued.

However, generally, Mac users have always been below 10% of PC users, most of them opt not to use Safari (over half use Chrome, half of whats left use Firefox, roughly; changes over time); in the mobile space, "100%" use Safari due to the anti-trust stance they have against their largest competitors (even if you install Chrome or Firefox or anything else, it is required to be an unoptimized Safari instance underneath, with zero access to any sort of GPU or Javascript optimization) but only a small fraction of handsets sold have been iPhones.

Apple says stuff like, almost 2 billion iPhones have been sold since the introduction of it in 2007, but there are 2 billion active Android devices out there currently.

Analysis like https://www.statista.com/statistics/266219/global-smartphone... (use https://cdn.statcdn.com/Statistic/265000/266219-blank-754.pn... to get around paywall, blue is Android, black is iOS) basically put a nail in Apple's coffin.

Like I've said on here before, if you have a lot of Apple users, you should support them. If you are a huge company, you can afford to deal with the monetary and cognitive overhead of dealing with a developer-hostile company.

But for average devs in smaller or medium sized businesses? I don't see the point to give Apple users priority over the majority. Treat them just as you would any other OS or any other browser, no special support just for them. They won't pay you more, in fact, Apple makes sure they pay you less via the 30% grab on out-of-app service signups they're shaking down big companies over.

The front page of HN is certainly familiar with Apple shakedown stories, at this point it's really hard to argue in favor of supporting Apple anymore than the bare minimum for as little gain as you get.

Re: Browser Font Rendering Inconsistencies

#22

Post by DiabloD3 »

andrewmcwatters wrote: post #13
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.

OSX font anti-aliasing adds about one weight to font rendering, its a known bug on Apple platforms. Apple is aware of it, considers it a feature, and won't fix.

Eventually the command line fixes won't work either.

Re: Browser Font Rendering Inconsistencies

#23

Post by aahhahahaaa »

andrewmcwatters wrote: post #20
aahhahahaaa wrote: post #19

Earlier quoted context omitted.

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…

Sorry, I misread.

The annoying aspect to me isn't the change in dimensions, but the inaccurate baselines. If we could reliably align text based on its baseline it wouldn't be an issue. "align-items: baseline" would be brilliant if it actually worked cross-browser.

It's pretty telling that Github doesn't even bother to solve the issue in their redesign, they've seemed to write off Firefox text alignment idiosyncrasies.

Re: Browser Font Rendering Inconsistencies

#24

Post by andrewmcwatters »

DiabloD3 wrote: post #21
kanobo wrote: post #12

Earlier quoted context omitted.

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.

Any websites that I work on, which I don't often anymore, use standards. If its broken in Safari, then Safari needs to support the agreed upon W3C standards. I don't personally do weird cutting edge stuff, its stuff generally that's been supported in Firefox and Chrome stable for years. Safari must implement these, or be discontinued. However, generally, Mac users have always been below 10% of PC users, most of them…

The thing is, I think this font-weight behavior is perfectly standard. The author isn't familiar with the standard at all, however.

Re: Browser Font Rendering Inconsistencies

#25

Post by andrewmcwatters »

aahhahahaaa wrote: post #23
andrewmcwatters wrote: post #20

Earlier quoted context omitted.

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…

Sorry, I misread. The annoying aspect to me isn't the change in dimensions, but the inaccurate baselines. If we could reliably align text based on its baseline it wouldn't be an issue. "align-items: baseline" would be brilliant if it actually worked cross-browser. It's pretty telling that Github doesn't even bother to solve the issue in their redesign, they've seemed to write off Firefox text alignment idiosyncrasies…

It would have been great had I known details like this much earlier in my career, but when people talked then about "pixel perfect" designs, I don't think most people understood then what sacrifices you have to make to do so! Box size calculations should be the same, I think, surely. But text specifically has no such requirements for equal precision.

In truth, that type of work would require you to know the output sizes across every supported browser.

Re: Browser Font Rendering Inconsistencies

#26

Post by andrewmcwatters »

ryanwhitney wrote: post #18
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 nothi…

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.

Re: Browser Font Rendering Inconsistencies

#27

Post by andrewmcwatters »

DiabloD3 wrote: post #22
andrewmcwatters wrote: post #13

Earlier quoted context omitted.

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

OSX font anti-aliasing adds about one weight to font rendering, its a known bug on Apple platforms. Apple is aware of it, considers it a feature, and won't fix. Eventually the command line fixes won't work either.

You do raise an interesting point about anti-aliasing adding to weights creating an "equivalent weight" of sorts to the font.

Thanks for mentioning this, it's made me think differently about font rasterization.

Re: Browser Font Rendering Inconsistencies

#28

Post by Silhouette »

andrewmcwatters wrote: post #10
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…

As far as I know, -webkit-font-smoothing doesn't change weight, it changes rasterization. What you describe in Photoshop also isn't weight, it's rasterization.[1] See my post below. This is developer error from not understanding the font-weight implementation. The real answer is browser implementors use an algorithm to determine the nearest available weight. Succeeded standards, depending on how up-to-date the browse…

As far as I know, -webkit-font-smoothing doesn't change weight, it changes rasterization. What you describe in Photoshop also isn't weight, it's rasterization.[1]

It is true that these settings control the rasterization, but it is also true and a well-known problem that different rasterizations (and in particular, the default rasterizations on different platforms) can result in different apparent font weights.

As you noted in your longer top-level comment, this doesn't actually seem to be the problem the original author encountered here, though.

Re: Browser Font Rendering Inconsistencies

#29

Post by andrewmcwatters »

Silhouette wrote: post #28
andrewmcwatters wrote: post #10

Earlier quoted context omitted.

As far as I know, -webkit-font-smoothing doesn't change weight, it changes rasterization. What you describe in Photoshop also isn't weight, it's rasterization.[1] See my post below. This is developer error from not understanding the font-weight implementation. The real answer is browser implementors use an algorithm to determine the nearest available weight. Succeeded standards, depending on how up-to-date the browse…

As far as I know, -webkit-font-smoothing doesn't change weight, it changes rasterization. What you describe in Photoshop also isn't weight, it's rasterization.[1] It is true that these settings control the rasterization, but it is also true and a well-known problem that different rasterizations (and in particular, the default rasterizations on different platforms) can result in different apparent font weights. As you…

Yeah, and as DiabloD3 mentioned as well, I think it's a very good reminder.

Re: Browser Font Rendering Inconsistencies

#30

Post by cuu508 »

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.

If you're using Firefox on Linux, check out https://nolanlawson.com/2020/05/02/customizing-fonts-in-fire...
Post reply on HN