Chrome vs. BlinkMacSystemFont: A Workaround

UPDATE 2020-04-28: Good news everyone! A workaround for this bug has landed in Canary (Chromium 84) and will be merged into the M83 release! The workaround described here still applies for Chromium 81.

The problem

As detailed before there’s this bug that shipped with Chromium 81 which somehow prevents the font-weight CSS property from being applied on the BlinkMacSystemFont font. Quite annoying, as that font is part of the widespread system font stack and affects all modern versions of macOS.

The Chromium bug itself is marked as a blocker for Chromium M83 – the next Chromium version – but as far as I can tell there’s no real progress being made on it. Above that the M83-based build of Google Chrome won’t start shipping until May 19, so we’re stuck for at least another month with this issue. Other browsers (such as Edge, Brave, etc.) might ship their M83-based build even later.


The Fix

As a workaround, some users have suggested to simply not use SF Pro (which is the outcome of using BlinkMacSystemFont) but that’s quite a hard measure I must say. Thankfully there’s a better solution. Thanks to Twitter I’ve come to known that the Inter font family is practically a drop-in replacement for SF Pro.

Here on I’ve adjusted my font stack to no longer use BlinkMacSystemFont and load Inter – served by Google Fonts – instead. To preserve other platforms to load their own system font, I’ve added Inter somewhere at the back of the line.

Here’s a diff of my CSS:

+ @import url('');


- font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", 'Inter', "Helvetica Neue", sans-serif;
+ font-family: -apple-system, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", 'Inter', "Helvetica Neue", sans-serif;

💡 Note that in the snippet above I’m loading all available font-weight Inter supports. It’s recommended to limit this and only load the font-weights you actually need. You can do this via the Google Fonts website


With this adjustment in place my website looks quite decent again. Let’s hope the Chromium team can fix this issue soon. In the mean time we can use Inter as workaround.

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Automatically Fix Bluetooth Audio Balance Drift in macOS with “Balance Lock”

It’s been over 10 years that I’ve been using macOS (then OS X) and every now and then I notice that the audio balance of my Bluetooth headset is off for no apparent reason.

Hmm, why is the balance for my headphone suddenly off?

Back in 2014 I was lucky enough to see this tweet by Shaun Inman float by, in which he linked to a manual solution using macOS’s built-in Audio Midi

Ever since then I’ve been taking those manual steps to fix it whenever the issue occurred (which is quite often).

☝️ I know, you can also do it through the System Preferences nowadays. Back then that wasn’t the case though.


As I encountered the issue again today, I wondered if there was no automatic way to fixing this issue. Turns out there is, with the utility app Balance Lock

Headphones a little off or noticing your audio isn’t quite centered? Balance Lock will keep your audio centered and fix the annoying left/right drift bug.

It’s simple to use and runs in the background un-intrusively.

You can find Balance Lock for free on the App Store, or install it using mas

mas install 1019371109

Come on Apple, fix this longstanding bug or Sherlock the shit out of this app 😉

Balance Lock →

💁‍♂️ I’ve also added this handy tool to ./freshinstall, a tool which I built to automatically configure macOS (Preferences, Dotfiles, Installed Software, etc).


Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Chrome vs. BlinkMacSystemFont: when bold is not bold

UPDATE 2020-04-28: Good news everyone! A workaround for this bug has landed in Canary (Chromium 84) and will be merged into the M83 release!

Today I noticed here on that the titles suddenly have gotten thinner in Chrome on macOS. Was this due to a recent WordPress Theme Update? Was it caused by a recent macOS update? Or was it the update to Chrome version 81 that broke my site?


I’m running WordPress here with (a slightly modified version of) the default Twenty Nineteen theme. The theme uses a so called system font stack for its titles:

h1, h2, h3, h4, h5, h6 {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
  font-weight: 700;

While the font stack itself was applied correctly – the font eventually used is BlinkMacSystemFont here on my Mac – the font-weight seems to be ignored by Chrome.


After some experimenting I’ve narrowed down the problem to its core, and have come to conclude that the issue is:

  1. Not WordPress-related. The issue is present on any site with elements that use the BlinkMacSystemFont font (which is only available on recent macOS installs).
  2. Only occurs when larger font-sizes (> 20px) are used.
  3. Chromium related: Latest Firefox and Safari still show the bold titles. Google Chrome and Edge Beta show the thin versions.
  4. Chromium 81+ related: Edge (based on Chromium version 80) works fine, Edge Beta (based on Chromium version 81) doesn’t. Chrome Canary (based on Chromium version 84) also has this issue.

Here’s a pen with a standalone test case. No matter what you set the font-weight to, the title always remains thin (on macOS, in a Chromium 81+ browser).

To be complete: I’m running the latest macOS Catalina, version 10.15.4 (19E266).


I’ve created a bug on the Chromium Bug Tracker for this, which by now has been confirmed. The problem indeed got introduced in Chrome 81 and is reproducible. If I understand things correctly, work is being done to have it fixed by Chrome 83, which is the next version of Chrome (there is no Chrome 82 as the release schedule got thrown around due to #coronavirus).

Currently there’s no workaround that you as a developer can implement, other than simply not using BlinkMacSystemFont. As a developer you can work around this issue by dropping BlinkMacSystemFont from your font stack and using the Inter Font Family instead. See for details.

💁‍♂️ It’s not the first time Chrome is having font issues. In Chrome 79 there was this weird issue that some people saw the font Hoefler Text being rendered as Hoefler Text Ornaments. The issue was never really fixed but seemed to have disappeared for most with the release of Chrome 80.

Chrome vs. WordPress: All Text Showing as Glyphs / Symbols 🤯

Ever since mid december I’ve had a few reports from people that they were seeing my blog – the thing you’re reading now – rendered in unreadable text. Instead of seeing a nice serif font, they got presented with some wingdings-like symbols for all the text when visiting through Chrome on macOS.

Very strange, as I myself am also using Chrome for my main browsing and am not seeing it. So I kind of ignored the first report, as I thought it was a standalone case: “The user visiting might have overwritten their local font stack, and therefore things went wrong” I thought to myself. After the second report I started to get suspicious though …


With a few Google Search Coupons in hand, I found that I wasn’t the only one with this problem, and that it’s related to the use of Hoefler Text. “Hoefler Text” is the font used for all regular text here on, as it is on many other WordPress sites as I’m basically running the default WordPress Twenty Nineteen theme with a few CSS tweaks sprinkled on top. For some weird reason “Hoefler Text” gets replaced with its “Hoefler Text Ornaments” counterpart when one has that font installed.


With the holidays I kinda forgot the whole thing, but after a third report today I dug deeper and found the root cause: it’s not a bug in a local font stack nor in WordPress itself, but it’s a bug in Chrome

The issue appeared between these two Chrome releases:

  • 78.0.3904.108 (not broken)
  • 79.0.3945.88 (broken)

And seems fixed in Canary:

  • 81.0.4001.0 (not broken)

It also seems to happen only on macOS 10.15.x

Brave browser on the same version seems affected too. No other browser is affected.


As this is a very specific browser bug, and WordPress themselves are awaiting a Chrome update. In the meantime I’ve updated the CSS here to no longer use Hoefler Text, falling back to Garamond.

🧐 On a side note: the font-stack is defined about 10 times in the default WordPress Twenty Nineteen theme, plastered all over the CSS file. Weird choice imho. Anyways: know that you’ll have to do as many adjustments to get it fixed.

🙏 Thanks go out to all who reported the issue (@wolfr_2, @tommyquissens, and @edwinm)

iTunes auto-rating all played tracks …

For more than a year it’s been bugging me that iTunes “sometimes” would auto-rate played tracks. It happened on some albums, yet not all albums. Back in May 2018 I posted this video on YouTube showing the behaviour:

As you can see iTunes here automatically rates “En Masse” (track 10) from the moment it starts playing.


Back then I couldn’t quite put my finger on it, yet today I found out when this behaviour occurs: it happens when you’ve rated the album itself. For whatever reason iTunes copies over the album rating onto each track when you start playing it.

I don’t like this behaviour, as it’s unwanted: an album can be 5 stars, yet that does not mean all individual tracks on it are 5 stars.

(*) For the “Nachtlicht” album (from the second video) I’d make an exception though … it’s an exceptionally great album by Eefje de Visser and would highly recommend it to all who speak Belgian/Dutch!

So, Apple, can you fix this?

Why a software patch is called a patch

Software Bugs

A common misconception is that a software bug is called a bug because of an actual bug that was once found.

The story goes that Grace Hopper found a moth stuck in Harvard University’s Mark II calculator in 1947 and that she taped it inside a logbook with the words “First actual case of bug being found”.

In reality Grace herself didn’t find the bug – somebody else from the team did – nor did they coin the term bug because of that event.

American engineers have been calling small flaws in machines “bugs” for over a century. Thomas Edison talked about bugs in electrical circuits in the 1870s. When the first computers were built during the early 1940s, people working on them found bugs in both the hardware of the machines and in the programs that ran them.

💁‍♂️ FYI: The logbook has been preserved and is now part of the collection at the Smithsonian (but not on display at the time of writing).

Software Patches

What seems to be legit however is the history of the term software patch. Back in the day when punched card coding was all the rage (although …), one actually had to put a patch of tape/cardboard over a wrongly punched hole in order to fix a bug.

Wikipedia tends to agree with this, even stating that whole sections would be replaced when needed:

Historically, software suppliers distributed patches on paper tape or on punched cards, expecting the recipient to cut out the indicated part of the original tape (or deck), and patch in (hence the name) the replacement segment.



Flexbugs – Flexbox issues and cross-browser workarounds for them.


This repository is a community-curated list of flexbox issues and cross-browser workarounds for them. The goal is that if you’re building a website using flexbox and something isn’t working as you’d expect, you can find the solution here.

Truth be told, most of the time “something is not as I’d expect” when using flexbox 😛

philipwalton/flexbugs →

Fitts’ Law vs. Apple on Windows, continued, again

Two years ago I wrote about Fitts’ Law vs. iTunes/Safari describing the lack of the upperleft and upperright pixels in the Windows distribution of Safari. The lack of those two pixels resulted in some really odd behavior (the upper right corner for example didn’t trigger the close button, as you clicked *through it*, hitting the close button of the application underneath). Luckely Apple soon set things straight and fixed the issues mentioned.

Continue reading “Fitts’ Law vs. Apple on Windows, continued, again”