Smooth Scrolling and Find In Page, a not so Smooth Combination …

There was this interesting Twitter conversation last week between Chris Coyier and Schepp last week. Apparently if you have Smooth Scrolling enabled, it also affects the behavior of Find in Page in Chrome: Whenever you want to go to the next result it will smooth scroll, instead of jump to it.

Schepp chimed in and offered the solution: leverage the :focus-within pseudo-class selector so that it’s only applied when the html has focus.

Combine it with prefers-reduced-motion and you’ll end up with this:

@media(prefers-reduced-motion: no-preference) {
    html:focus-within {
        scroll-behavior: smooth;
    }
}

There’s on nasty side-effect though: in-page jump links that refer to the id of an element will no longer work. You’ll actually need to sprinkle some <a name="…">#</a> elements over your markup to make those work smoothly …

Fixing Smooth Scrolling & Page Search →
Chromium Bug #866694 →

Chrome is about to hide parts of the URL

In Chrome 86, we’re going to experiment with how URLs are shown in the address bar on desktop platforms. Our goal is to understand — through real-world usage — whether showing URLs this way helps users realize they’re visiting a malicious website, and protects them from phishing and social engineering attacks.

A shame they didn’t follow Jake’s proposal (as talked about in HTTP 203 and pictured below) though, as that pleases both a non-technical as a technical audience.


Screengrab of Jake’s Proposal

But then again I can imagine that there’s no good reason to show a bunch of seemingly random characters – which us developers can parse and interpret – to regular users like my mum. Most web-related support calls from her end up with me asking “are you on bla.com” with the rest of the URL not being entirely irrelevant, or me instructing her to “go to foo.com and search for X” instead of spelling out the whole URL.

Chrome is about to hide parts of the URL →

(And yes, there is an option to “Always show full URLs”)

New in Chrome 84

Chrome 84 has been released, which contains some nice additions. Pete LePage walks us through:

Chrome 84 is rolling out now! Users can start common tasks within your app with App Icon Shortcuts. The Web Animations API adds support for a slew of previously unsupported features. Wake Lock, and the Content Indexing API graduate from origin trial. There are new origin trials for Idle detection and SIMD. And there’s a whole bunch more. Let’s dive in and see what’s new for developers in Chrome 84!

I’ve written about the Wake Lock API before, which has been part of Chrome’s Origin Trials since Chrome 79.

New in Chrome 84 →

How to enable HTTP3 in Chrome / Firefox / Safari

Mattias recently tweeted that his website can now be served over HTTP/3 “even though no browser supports it yet”.

While it’s true that no browser supports it out of the box right now, there are options to enable HTTP/3. Here’s how.

🧪 As with all experimental technolgy/features: things might break! Be warned!

~

Google Chrome

If you search chrome://flags you’ll find an option named “Experimental QUIC Protocol” which you can enable:

That alone however won’t do. You’ll also need to enable a specific HTTP3 version, apparently. This extra change cannot be done through chrome://flags, but only through a command line option.

To fully enable HTTP/3 in Chrome, you must launch it with the command line options --enable-quic --quic-version=h3-27 :

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-quic --quic-version=h3-27

Firefox

Set network.http.http3.enabled to true in about:config

At least Firefox 75 is required.

Safari

Safari Technology Preview Release 104 which was just released has added HTTP3 as an experimental feature. To enable it, you’ll first need to enable the “Develop” menu through its settings.

If you’re running (the unreleased) macOS 10.16 / iOS 14, you can now use the Develop menu and underneath Experimental Features enable it.

🙏 Thanks to Kai for digging up the fact that macOS 10.16 is required.

~

How to test this?

A good site to test your connection is https://www.litespeedtech.com/. Visit that site and open the DevTools of your browser (SHIFT+CMD+I). In the Network tab enable the protocol column and refresh the page.

Here’s an example of Firefox:

quic.rocks is also a good site you can use. I did notice that Firefox for example sometimes loads that site using HTTP/1.1 and sometimes using HTTP/3 … experimental features, right? 😉

~

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 Extension Webpack Boilerplate

If you ever want to create a Chrome Extension, this repo might come in handy:

A basic foundation boilerplate for rich Chrome Extensions using Webpack to help you write modular and modern Javascript code, load CSS easily and automatic reload the browser on code changes.

Chrome Extension Webpack Boilerplate →

Conceal sensitive information in the Azure Portal with the “Azure Mask” browser extension

If you’re ever doing a livestream you might run into the problem that you’re about to expose sensitive information on your screen, such as UUIDs, emails, passwords, etc. For Azure Portal specifically there’s a browser extension called Azure Mask that does it all for you:

This is a browser extension that will mask GUIDs (such as Subscription IDs), email addresses, keys, and connection strings with a blur. The intention of the extension is to make it easier to do screen recordings without revealing sensitive, personal, account information that may show up on screen. It will only run and apply against Azure portal URLs. It’s available in Chrome and Firefox.

Looks really handy!

azure-mask (GitHub) →

⚠️ Unfortunately you can’t install it from the Chrome Web Store due to a “trademark infringement on the name” but you can always grap a .zip from the releases page and load it as an unpacked extension.

👀 If you’re using Visual Studio Code and recording that, you can use Cloak to conceal secrets in ENV files.

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 bram.us, 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)

Quieter Permission UI for Notifications coming to Chrome 80

Looking forward to this Chrome 80 feature:

To protect notifications as a useful service for users, Chrome 80 will show, under certain conditions, a new, quieter notification permission UI that reduces the interruptiveness of notification permission requests. Immediately after the Chrome 80 release, users will be able to opt-in to the new UI manually in Settings.

Instead of that pesky dialog, you’ll get this subtle notification:

💡 No worries: the blue bubble will only we shown once.

Above that, if you’re a user that typically blocks notifications, Chrome will automatically enable the quieter UI for you 🙂

Quieter permission UI for Notifications →

Emulate Dark Mode using Chrome DevTools

Coming to the next version of Chrome is a way to emulate “Dark Mode” using the DevTools. With the DevTools open and focused, hit SHIFT+CMD+P and choose “Emulate CSS prefers-color-scheme: dark from the menu

You can also access the option via the Rendering panel.