Reading List #17

Hello 😎

It was a sunny week in Zurich and felt like spring for the first time this year. Looking forward to warmer times and to the change to daylight saving time, which will happen tomorrow in Switzerland.

I spent most of this week with some client work and more getting used to with the block editors’ theme.json and stuff like that. As promised last week, I added some of the links that helped me getting started.

Frontend Development

πŸ‡ Animations

This is a great explainer of how the rendering in a browser works, and what we can do or should avoid to make animations smooth. I knew that some properties can be more performant than others, but wasn’t aware that transform for example seems to be a fairly cheap thing to calculate. Intuitively, I would have put them in the “more expensive” bucket.

Also, the CSS Triggers site mentioned in the article is a pretty cool visual reference to see how expensive different CSS properties are in different browsers.

Reza Lavarian – Web Animation Performance Fundamentals – How to Make Your Pages Look Smooth

🎚 How to Build a Switch Component

Adam Argyle covers in great detail how to build a custom switch component. He chose to use a checkbox with a label, custom properties and a bit of JavaScript to progressively enhance the UX. Definitely worth a read and I got a few ideas to improve a switch we built just recently.

Building a switch component

🧠 Why !important was invented

Do you know, how !important came to be? I certainly didn’t. Here’s Steven Pemberton, one of the co-designers of the very first CSS specs, explaining it:

CSS co-designer here.

!important was added for one reason only: laws in the US that require certain text to be in a given font-size. !important stops the cascade from changing it.

Anything else is probably misuse, and a sign you may not understand the cascade properly.

Steven Pemberton (twitter)



If you don’t know by Carolina Nymark, you should definitely go check it out. It’s packed with tutorials about the newest developments in the block editor, block themes and Gutenberg. No matter whether you’re starting out or are looking for some specific information, this site got you covered. These two articles helped me in particular in the last two weeks:

Course: Full site editing for theme developers

Lesson: Theme.json typography options

πŸŽ₯ Controlling a classic theme with theme.json

One thing I got wrong about theme.json in the beginning was thinking it was only for full site editing or the new “block” themes. It was just last week that I understood the value of adding a theme.json to your existing “normal” theme, to control your theme and the editor experience for your clients. And it’s much easier and clearer than by calling add_theme_support() or remove_theme_support() all over your functions.php. This video by Ryan Welcher gives you a good overview of some of the things you can do.

YouTube – Controlling how a theme.json affects your classic WordPress theme | WordPress 5.9 Full Site Editing

πŸ“œ theme.json Specification v2

This living specification of theme.json lists all the settings and properties that can be controlled with theme.json.

theme.json version 2 – living specification

Other / Random

πŸ•΅οΈβ€β™€οΈ Beyond Radar

Making yourself independent from facebook and Google can sound like a lot of work. But it’s actually not that hard to replace most of what they provide with other tools and channels. Channels that you own and control. I just stumbled across this new(?) community by Dave Smyth – Beyond Radar – which claims to be a community of businesses and freelancers that don’t want to rely on Facebook, Google and other marketing techniques that fuel surveillance capitalism.

Below Radar is a space for business owners and freelancers to help each other take a different route. By sharing our experiences, we can forge a path that breaks free of these platforms, leading the way for others.

Dave Smyth – Beyond Radar

Sounds like a good idea to me.

Beyond Radar

πŸ”ͺ Don’t design for the worst people

Jorge Arango, author of the book “Living in Information“, mentions a Tim Ferris interview with Jimmy Wales of Wikipedia. In an analogy, Jimmy Wales compares designing for the worst people and outcomes to steak knives in a restaurant and why we don’t live in cages because of them. This quote he mentions is worth remembering, every time you feel like you have to put guardrails into your design to prevent the worst of possible outcomes.

… if you design for the worst people, then you’re failing design for good people.

Jimmy Wales on the Tim Ferris Podcast

Jorge Arango – Jimmy Wales on Constraints for Bad Behavior

β˜€οΈ Ok, that’s it for this week. Have a nice weekend!

Made with ❀️ in Switzerland