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.

I posted a tweet yesterday that was met with some controversy, so I thought it would be a good idea to unravel it.

We tend to think of components as things that belong to a framework. After all, React has components, Vue has components, Angular has components…it's just how we've always used them.

A great trick to find the closest element in the DOM that matches an arbitrary selector is Element.closest().

The new :focus-visible CSS selector lets us remove unsightly focus rings that often result in developers adding this to their stylesheets: