#269: The Color Blue, Neat Design Patterns, and Problems with Scrolling on the Web

[Robin]: Let’s start this week off with something odd and fun. I stumbled upon this interesting form pattern by Hakim El Hattab:

This is neat because I’ve never thought that a focus state could have flair and a personality—I’ve always seen those states as accessibility guides to help people quickly navigate around and understand where they are on the page. But nope! I was dead wrong here: focus states can be bubbly and quirky and weird!


Speaking of patterns, one that I’ve started to not only miss but genuinely require from apps and websites these days is cmd + k. In lots of apps, like Slack and Notion, when you hit that shortcut a quick search UI pops up and lets you navigate to different sections. In Notion, for example, you can jump from one page to another without having to go back back back to a previous page.

That’s why I got pretty excited about kbar earlier this week. It’s a “a fully extensible command+k interface for your site” which looks like this:

Gosh, I love this pattern.


I loved this piece by Elise Blanchard all about why hyperlinks are blue:

As a user experience designer who has created websites since 2001, I’ve always made my links blue. I have advocated for the specific shade of blue, and for the consistent application of blue, yes, but I’ve never stopped and wondered, why are links blue? It was just a fact of life. Grass is green and hyperlinks are blue. Culturally, we associate links with the color blue so much that in 2016, when Google changed its links to black, it created quite a disruption.

Great breakdown of all the history here and this shows how user interfaces are remixes of remixes of remixes of…

Josh Comeau has been on a roll lately and I feel like this newsletter is slowly becoming The Josh Comeau Show—but!—for good reason. The other day, he wrote this fantastic piece about shadows and how to design them properly with CSS.

He shows this example:

In my humble opinion, the best websites and web applications have a tangible “real” quality to them. There are lots of factors involved to achieve this quality, but shadows are a critical ingredient.

When I look around the web, though, it’s clear that most shadows aren’t as rich as they could be. The web is covered in fuzzy grey boxes that don’t really look much like shadows.


Patrick Brosset wrote this nifty piece all about the gap CSS property. I don’t know about you, but I think this is the one property I take for granted these days—I can’t imagine building a UI today without it.

Here’s the niftiest of nifty things in this piece that I had never thought about though: styling the gap:

Styling gap in Flexbox and CSS Grid would be really useful. The sad news is that it isn’t supported anywhere today. But the good news is that it could be in the near future. This has been discussed over at the CSS working group and is in the works in Firefox. Once we have a working implementation in Firefox along with the spec proposal, perhaps it will drive implementation in other browsers.

Interesting! I’ve never thought of needing to style the spaces between columns or rows, but I can see something cool coming out of that.


Google just came out with the results for their scroll survey report and it’s mighty interesting; a lot of us web devs find scrolling difficult to work with and/or straight up annoying. Chris followed up that report with a write-up of his own thoughts:

[…] I think even smooth scrolling is a little frustrating in how you can’t control the speed or other behaviors of it. For example, you can’t say “smooth scroll an on-page jump-down link, but don’t smooth scroll a find-on-page jump.”

And that’s not to mention scroll snapping, which is another whole thing with the occasional bug. Speaking of which, Dave had an idea on the show the other day that was pretty interesting. Now that scroll snapping is largely supported, even on desktop, and feels pretty smooth for the most part, should we start using it more liberally, like on whole page sections? Maybe even like…

/* Reset stylesheet */
main, section, article, footer {
  scroll-snap-align: start;

This is a great idea! And it will come as a surprise to no one that I believe scrolling on the web requires a bit of rethinking. Take the flashy Apple websites, for example, which are always annoying because they stop me in my tracks from scrolling around… but sometimes it’s cool to slow down the pace of reading when it makes sense.

Take a look at this great example, though, where Scott Jehl uses scroll snapping to make a responsive table. Each of the table cells always snap into place as you scroll around:


I’ve been enjoying these short and sweet ShopTalk videos where Chris and Dave talk about the latest nifty thing. This video about accent-color, which I’m dead excited about, is definitely worth checking out if you haven’t heard of that before.

Shortcut (formerly Clubhouse.io)

Imagine how much more you could get done if your project management tools didn’t make you sigh. Shortcut is the ideal solution for task management, bug tracking, iteration planning, and reporting. Delight the scrum gods and try us out for free.

Strattic Free Trial

Strattic is an all-in-one static site generation and hosting platform that instantly optimizes WordPress by converting it to a static architecture. The results: blazing performance, unprecedented site security, and infinite scalability.

[Chris]: Since you’re reading this technical newsletter, I imagine you have at least a passing interest in technical writing. I definitely do. I do it, and I want to be better at it.

There is a lot of approaches to technical writing. It can be funny! Documentation usually isn’t the place for that, but blog posts certainly can be, and it doesn’t have to be at the cost of quality or usefulness. It can be short form or long form. Technical writing can be in printed books, PDF whitepapers, eBooks, blog posts, or any number of other places, and they all have their place. But there is one thing, aside from being technical, that the writing also needs to communicate: the technology. It needs to help the reader understand, not confuse them.

Toward that end, Julia Evans’ recent post “Patterns in confusing explanations” is excellent. Rather than focus on what works, sometimes you gotta focus on what doesn’t. Julia documents 13 confusing patterns. Here’s one: jargon that doesn’t mean anything.

Let’s talk about this sentence from this chapter on commit signing:

Git is cryptographically secure, but it’s not foolproof.

“Cryptographically secure” is unclear here because it sounds like it should have a specific technical meaning, but it’s not explained anywhere what’s actualy meant. Is it saying that Git uses SHA-1 to hash commits and it’s difficult to generate SHA-1 hash collisions? I don’t know!

Using jargon in a meaningless way like this is confusing because it can trick the reader into thinking something specific is being said, when the information they need is not actually there. 

Technology is complicated enough. We really need to pick words carefully, say what we mean, and ensure those meaningful words are the widely agreed-upon standard definitions.

Read Julia’s post for more strong examples that aren’t afraid of pointing at very specific examples.