On the eve of February, I was inspired to tweet about web components. What started as a simple thought quickly turned into a series of tweets that folks seem to find useful. I've adapted the thread and I'm posting it here for prosperity.

I've concluded that successful "makers" have one thing in common: luck.

Update (December 23, 2024): Check out my latest post on this topic: Revisiting FOUCE

Somewhere buried in my dusty basement lives a signed copy of Dan Cederholm's classic book Bulletproof Web Design. I purchased it during my first trip to An Event Apart in 2007. This book meant a lot to me back then, and almost 15 years later, many of its concepts still hold true.

The question of whether or not component APIs should be locked down at the code level comes up quite a bit. For example, if a button spec only calls for primary, secondary, and tertiary variants, should we still expose parts and custom properties so users can make further customization as needed?

The EyeDropper API has landed in Chrome and Edge 95! This is a simple promise-based API that lets you select a color from anywhere on the screen. Let's dive in and see how it works.

Love them or hate them, web components ("custom elements") are making a huge dent in the world of front-end development. As of today, close to 18% of page views in Chrome are registering web components. That's an insane amount of usage!

I stumbled upon a short post that intrigued me. In it, the author claims that the cure for boredom is superpowers. Not superpowers in the Superman sense, but ones that we can teach ourselves.

One-off variations aren't uncommon, but they don't belong in your design system. You're design system isn't solving for every possible use case — it's encouraging visual consistency and efficient development. Use custom styles for one-offs.

We recently had a design for an "alert" component with an actions slot. In the spec, only secondary buttons were allowed in it.