New in Chrome 89

Pete LePage walks us through the additions in Chrome 89.

🤩 I’m honored to have my WebHID Daft Punk Sound Board be featured in the “WebHID, WebNFC, and Web Serial section there.

Let’s hope other browser vendors follow soon with top level await, as Chromium is the only browser to support it at the time of writing.

New in Chrome 89 →

Chrome 88 – What’s New in DevTools

I especially like the New CSS Angle Visualization Tool 🙂

What’s New In DevTools (Chrome 88) →

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 bram.us 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('https://fonts.googleapis.com/css2?family=Inter&display=swap');

…

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

Easily link to Text Fragments in Chrome with the “Copy Text Fragment URL” Plugin

One of the additions that shipped in Chrome 80 is the ability to link to Text Fragments. To easily create such links, I stumbled upon the “Copy Text Fragment URL” Plugin which adds an extra option to the context menu.

Handy! Makes me wonder why it’s not a default Google Chrome feature.

Chrome Web Store: Copy Text Fragment URL →

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 bram.us 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 https://www.bram.us/2020/04/24/chrome-vs-blinkmacsystemfont-a-workaround/ 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.

Tweet from the Chrome Address Bar by adding a Custom Search Engine

TIL: Chrome allows you to define a Custom Search Engine (CSE) by which you can search sites. The cool part is that you’re not really limited to search only, and that you can abuse these CSEs to become more productive. In this post I’ll show you how to tweet from the Chrome Address Bar.

🦊 Firefox User? You can achieve the same result by adding a bookmark.

~

TIL: Custom Search Engine

The idea was sparked by this tweet by Rowan Merewood. Rowan created a CSE to quickly go to a Zoom meeting by simply typing zoom meeting-id in the Chrome Address Bar.


Don’t mind the word “Search”: Upon hitting ENTER the browser won’t search Zoom but will directly go to the Zoom meeting with ID 123456789.

A Custom Search Engine (CSE) is defined by three parameters:

  • Search Engine: The name that will be shown in the Chrome Address Bar when typing in keyword
  • Keyword: The keyword that needs to trigger the Search Engine
  • URL: The URL that will be visited once you press enter. Use %s where you want your “search term” to appear.

Here’s how Rowan has define his Zoom CSE:

~

DuckDuckGo’s !tw command

Earlier today I saw Šime Vidas tweet about using DuckDuckGo’s !tw command interpretation to quickly compose a new tweet.

As he uses DuckDuckGo as his default search engine, the trick works fine from the address bar:

  1. The Address Bar will pass the entered term to search DuckDuckGo
  2. DuckDuckGo will interpret the !tw prefix and redirect to Twitter’s Compose Dialog

For users like me, who don’t use DuckDuckGo as their search engine, that won’t work.

~

1 + 1 = 2

Combining both ideas, I came to create a Custom Search Engine for Chrome that will allow me to quickly tweet from the Address Bar:

I’ve define a CSE so that the tw keyword will directly go to Twitter’s Compose Dialog. To define this CSE yourself, go to chrome://settings/searchEngines and add a new CSE with the following details:

  • Search Engine: Compose Tweet
  • Keyword: tw
  • URL: https://twitter.com/compose/tweet?text=%s

From now on you can compose a tweet by simply typing tw This is a tweet in the Chrome Address Bar.

Combine that with CMD+L, just like Šime did, and you can quickly tweet out links:

  1. Visit URL
  2. Hit CMD+L to focus the Address Bar
  3. Hit CMD+← to put the cursor before the URL
  4. Type in tw (with space) and hit enter

Cool!

~

Call to developers

I see lots of uses for this. You could create these kind of productivity shortcuts to go quickly to Twitter profile pages, visit NPM packages, auto-archive URLS on The Wayback Machine, etc. (Ab)using CSEs like this once again underlines the importance of bookmarkable URLs and the ability to precompose data along with that.

Do note that many sites (such as the mentioned Twitter, GitHub, NPMJS, etc.) already provide CSEs to actually search them. Same goes for WordPress blogs, such as this one right here: simply enter bram.us searchterm in the Chrome Address Bar and after hitting ENTER it’ll search this blog for the given searchterm.

~

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.

New in Chrome 80

Chrome 80 recently got released, with some nice new features.

To me the highlights are:

New in Chrome 80 →

💁‍♂️ Also on my list of highlights is Linking to text fragments using a special URL fragment in the form of :~:text=[prefix-,]textStart[,textEnd][,-suffix]. It’s a but clunky to work with as you can’t manually change the fragment in the URL and hit enter to make it work, you’ll need to actually follow it through a link.


Text Fragment linking in action

Native Image Lazy Loading in Chrome Is Way Too Eager

UPDATE 2020.07: the thresholds have been adjusted to be less eager:

For the Web Performance Calendar Advent, Aaron Peters took a close look at Chrome’s Native Lazy Image Loading, and noticed that it’s a bit too eager:

I see the lazy-loaded images being fetched at ~ window.pageYOffset = 8500 on desktop and they become visible at ~ window.pageYOffset = 11500. So, the image lazy-load logic of Chrome seems to be: if the image is 3000 or less pixels below the viewport, load it.

3000 pixels… that is a lot!

Google’s documentation on Native Lazy Loading clearly states that the distance threshold depends on several factors:

  • The type of resource being fetched (image or iframe)
  • Whether Lite mode is enabled on Chrome for Android
  • The effective connection type

Checking the relevant Chromium Source, I see these values for the difference connection types:

//
    // Lazy image loading distance-from-viewport thresholds for different effective connection types.
    //
    {
      name: "lazyImageLoadingDistanceThresholdPxUnknown",
      initial: 5000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPxOffline",
      initial: 8000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPxSlow2G",
      initial: 8000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPx2G",
      initial: 6000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPx3G",
      initial: 4000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPx4G",
      initial: 3000,
      type: "int",
    }

Yes that’s right: the slower your connection, the more eager lazy loading will work. Seems a bit of a conundrum: on one hand you don’t want images to load too soon (push for a lower distance threshold), but on the other hand you want to have the images present when scrolling (pushing for a higher distance threshold).

Native Image Lazy Loading in Chrome Is Way Too Eager →

SVG favicons in Chrome

A commit that landed in Chromium (and which will be available in Chrome 80) is support for SVG favicons. 🎉

🦊 Firefox already has support for SVG favicons, ever since version 41

Since most (all?) browsers always make a request to favicon.ico you can also serve an SVG at that location with the image/svg+xml MIME Type – As per tip by Mathias

Above that it’s also possible to use prefers-color-scheme in your SVG icon, thus supporting Light/Dark Mode:

🐛 There’s on small bug though: you need to refresh the page after changing to/from Dark Mode for the favicon to change.

Dark Mode Favicon Demo →

Ungoogled Chromium is Google Chrome, but without Google

If you’re not too fond of Google but do want a Chromium-based browser that is as close to Google Chrome as it can be (along with some extras), be sure to check out Ungoogled Chromium:

ungoogled-chromium is Google Chromium, sans dependency on Google web services. It also features some tweaks to enhance privacy, control, and transparency (almost all of which require manual activation or enabling).

ungoogled-chromium retains the default Chromium experience as closely as possible. Unlike other Chromium forks that have their own visions of a web browser, ungoogled-chromium is essentially a drop-in replacement for Chromium.

Ungoogled Chromium Source (GitHub) →
Ungoogle Chromium Binaries →