More in CSS & Design Systems — page 3
Bundling a component library for tree-shaking
WHAT IT TESTS: Optimizing a library so consumers ship less code. OUTLINE: ship ES modules, mark sideEffects false, preserve named exports, and externalize peers so consumers tree-shake and code-split.
Releasing a breaking Button change with SemVer
WHAT IT TESTS: Handling breaking changes responsibly under SemVer. OUTLINE: bump the major version, write a changelog and migration guide, deprecate before removing where possible, and communicate clearly.
Automated visual regression testing for components
WHAT IT TESTS: Catching unintended visual changes automatically. OUTLINE: render components in known states, capture screenshots, diff against approved baselines in CI, and require human review of differences.
Packaging a design system as an npm dependency
WHAT IT TESTS: Distributing shared code as a versioned package. OUTLINE: publish to an npm registry, with package.json holding the version, entry points, and dependencies, and version it via SemVer.
Why design systems use Sass or PostCSS
WHAT IT TESTS: Knowing what preprocessors add over plain CSS. OUTLINE: Sass adds variables, nesting, mixins, and functions for reuse; PostCSS transforms CSS via plugins like autoprefixer. RED FLAG: claiming native CSS variables make them entirely obsolete.
Respecting prefers-reduced-motion in a design system
WHAT IT TESTS: Building motion accessibility into system architecture. OUTLINE: gate CSS animations behind the media query, read the same preference in JS via matchMedia, and centralize motion tokens. RED FLAG: killing all motion instead of reducing it.
Building an accessible combobox with ARIA
WHAT IT TESTS: Combobox ARIA wiring and focus strategy. OUTLINE: input has role combobox with aria-expanded and aria-controls, listbox holds options, and choose aria-activedescendant to keep focus in the input versus roving DOM focus.
Announcing status messages with ARIA live regions
WHAT IT TESTS: Announcing dynamic updates without stealing focus. OUTLINE: use a live region with aria-live polite or role status, ensure it exists in the DOM beforehand, and insert text to trigger announcement. RED FLAG: moving focus to the message.
ARIA roles for an accessible tab interface
WHAT IT TESTS: Correct ARIA wiring for tabs. OUTLINE: tablist contains tabs, each tab uses aria-selected and aria-controls, panels use role tabpanel with aria-labelledby, and arrow keys move between tabs. RED FLAG: making every tab a Tab stop.
Managing focus in an accessible modal dialog
WHAT IT TESTS: Keyboard focus management for modal dialogs. OUTLINE: move focus in on open, trap Tab within the dialog, close on Escape, and restore focus to the trigger on close. RED FLAG: leaving focus behind the modal in the background.
Associating a label with a form input
WHAT IT TESTS: Foundational accessibility for forms. OUTLINE: explicit association via for and id, implicit by wrapping the input, and why this gives screen readers an accessible name and larger click target. RED FLAG: using a placeholder as the label.
Shadow DOM encapsulation vs CSS Modules
WHAT IT TESTS: Understanding real browser encapsulation versus build-time name scoping. OUTLINE: Shadow DOM creates a separate tree blocking selectors both ways, CSS Modules only rename classes, and global styles need explicit bridges.
The polymorphic 'as' prop pattern
WHAT IT TESTS: Building reusable components with correct typing and ref forwarding. OUTLINE: render the element from an as prop, infer props from the chosen element, and forward refs. RED FLAG: ignoring types or dropping the ref.
Controlled vs uncontrolled Modal component
WHAT IT TESTS: API design judgment for component state ownership. OUTLINE: uncontrolled is convenient but inflexible, controlled gives parent full power and predictability, and a hybrid supports both. RED FLAG: claiming controlled is always better.
CSS Modules versus Styled Components
WHAT IT TESTS: CSS scoping tradeoffs. OUTLINE: CSS Modules scope via build-time hashed class names with near-zero runtime; Styled Components scope via runtime CSS-in-JS with easy dynamics but a runtime cost. RED FLAG: claiming one is strictly best.
Accessible composite TextField component
WHAT IT TESTS: accessible composition and prop forwarding. OUTLINE: associate label and input via matching for and id, generate a unique id, spread remaining props onto the native input. RED FLAG: a label not tied to the input, or swallowing native props.
Customize a Button without !important
WHAT IT TESTS: designed-in customization. OUTLINE: expose CSS custom properties as a styling API, accept className or style overrides, keep internal selectors low specificity so overrides win cleanly. RED FLAG: reaching for !important.
Designing a Card component API
WHAT IT TESTS: clean component API design. OUTLINE: simple props for title and image, but children or slots for arbitrary content instead of a string prop, keeping it composable. RED FLAG: passing HTML as a string or via dangerouslySetInnerHTML.
Reusable Button with hover, focus, disabled
WHAT IT TESTS: semantic, accessible button states. OUTLINE: use a real <button>, style :hover, a visible :focus-visible ring, and the [disabled] attribute that also blocks interaction. RED FLAG: a clickable <div> or removing focus outlines.
Integrating design tokens with Tailwind CSS
WHAT IT TESTS: tokens plus utility-first integration. OUTLINE: feed tokens into Tailwind's theme config (or v4 CSS theme) so utilities derive from one source; a parallel setup causes drift. RED FLAG: maintaining tokens and Tailwind values separately.