The Best Of The Internets

I got really excited about aural style sheets back in the day, only to have my hopes dashed when I discovered no one supported them. Then came ReadSpeaker (and its ilk), which started to move in that direction, but the solutions are far from perfect.

I even tinkered a bit with the Speech Synthesis API to achieve something akin to a functional listening experience for this blog. Would love to go back to doing it in CSS though. I hope this happens!

Curious to know what’s going on with Progressive Web Apps in 2022? The 2022 edition of the Web Almanac is out, with an excellent chapter on PWAs by Diego Gonzalez and Beth Pan.

Early on in my journey as a web designer, Molly Holzschlag taught me the importance of controlling everything you can, up until the point that you realize you must relinquish control. In this piece, Jeremy Keith explores the tension around control and, ultimately, echoes Molly’s perspective:

The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

I love this piece from Tomas Pustelnik. It walks through all the work you need to do to build a fake button using a div when you could have just used a button.

It’s kinda the inverse of a piece I wrote for Smashing a few years back: Developing Dependency Awareness.

When you’ve worked on the web for as long as I have, you see trends come and go. I’ve witnessed at least three different eras where folks began to put all their eggs in the JavaScript basket, only to realize the massive hits they were taking to performance.

In this piece for WebPageTest, Scott Jehl uses a new “experiments” feature to demonstrate how serving HTML would make a ton of popular websites much, much faster. Some of these companies learned this lesson previously (and even wrote about it) only to have thrown their own advice out the window, which is disappointing.

Serving HTML will always result in faster page loads. There is no way around that. Sending your JavaScript framework to the client and having it render the HTML adds a ton of extra steps:

1. Download skeleton markup
2. Download high priority JavaScript file(s) and CSS
3. Load JavaScript program into memory
4. Execute JavaScript
5. Generate actual markup (and replace skeleton)
6. Request assets referenced in markup (e.g., images, videos)
7. Render page
8. Load deferred assets

Compare that to the HTML-first route:

1. Download markup
2. Download high priority JavaScript file(s) and CSS
3. Request assets referenced in markup (e.g., images, videos)
4. Render page
5. Load deferred assets

Sure, on subsequent navigations having JavaScript request only the bits and pieces you need is a performance win, but that first render is a beast. And you can totally load that JavaScript later, after the page is rendered.

This piece offers an excellent overview of a handful of common biases and how they can negatively impact our work.

For even more detail (and biases), I highly recommend David Dylan Thomas’ book Design for Cognitive Bias.

This post offers straightforward guidance on how to ensure your interactive components are easily understood by people who rely on screen readers and other assistive technologies. And, honestly, Hidde’s authoring guidance is applicable to the main content of your site as well.

Another great post about the combined power of ARIA & CSS to enable your designs from truly semantic markup.

This is an approach I’ve used often with complex interfaces like tabs and it works a treat.