tailwind

12 posts

Posts in this series

Sort by:

Building a Badge Component — Variants, Sizes, and Dot Indicators

Badge is the first purely presentational primitive in this series — no form integration, no event handling, no focus management. That simplicity is deceptive. A Badge that looks right in isolation often breaks inside a nav item, a table cell, or an avatar. The decisions that make it composable are worth getting right now.

Building a Label Component That Actually Connects to Its Field

We've referenced a Label component in every form field article so far without building it. That's intentional — you need to understand what the Label connects to before you understand what it needs to do. Now that we have Input, Textarea, Checkbox, RadioGroup, Select, and Toggle, the Label's job is clear: it's not just styled text. It's the accessible name of a form field, and it carries required indicators, optional markers, and disabled state as part of that responsibility.

Building a Toggle / Switch Component from Scratch

Toggle and Checkbox look similar but mean different things. A Checkbox records a choice in a form — you submit it later. A Toggle applies an effect immediately — dark mode on, notifications off, feature enabled. That semantic difference changes the HTML element, the ARIA role, and the user's expectation of what happens when they interact with it.

Building a Select Component — When to Use Native and When to Go Custom

The Select is the component where most UI libraries make a hard choice and then pretend it was easy. Native select elements are accessible and mobile-friendly but nearly impossible to style. Custom selects look great but carry the full weight of keyboard navigation, screen reader support, and focus management. We're building both — and being honest about when each one is the right call.

Building a Radio Group Component with Keyboard Navigation

A group of radio inputs is not just a list of checkboxes that only allow one selection. It's a distinct ARIA pattern with its own keyboard contract — arrow keys move between options, Tab moves out of the group entirely. Get this wrong and keyboard users are stuck tabbing through every option one by one. Get it right and the group behaves exactly as assistive technology and keyboard users expect.

Building a Checkbox Component — Custom Styles Without Losing Native Behaviour

Custom checkboxes are where most UI libraries make their first real accessibility mistake. They replace the native input with a styled div, wire up click handlers, and forget about keyboard navigation, screen readers, and the indeterminate state. We're keeping the native input and styling around it — all the customisation, none of the accessibility regressions.

Building a Textarea Component That Grows with Its Content

A fixed-height textarea is one of those small friction points that quietly frustrates users. They type more than the box holds, lose sight of what they wrote, and start scrolling inside a tiny rectangle. Auto-resize solves this in about ten lines — but there are a few details that make the difference between a resize that feels native and one that jumps around.

Building a Design Token System with CSS Custom Properties and Tailwind v4

Hardcoded colors feel fine when you're building for yourself. The moment someone else installs your library, they become a problem — every component locked to your brand's blue, with no clean way to change it. CSS custom properties fix this at the root. Set them up once and every component in the library becomes themeable for free.

Building an Input Component with Validation States and Accessibility Built In

A plain HTML input gets you 20% of the way there. The other 80% is validation states, error messages, label connections, ref forwarding, and accessibility attributes that most implementations bolt on as an afterthought. We're building all of it into the component from the start.

Building a Button Component That Handles Every Real-World Variant

The Button is the first component every UI library builds and the one most libraries get wrong. Not because buttons are hard — because the naive implementation handles the happy path and nothing else. Loading states, disabled behavior, icon composition, and rendering as a link all require deliberate decisions. Here's how to make them once and never revisit them.

Showing 1 - 10 of 12 posts