This course assumes real, working CSS knowledge — css1, css2, and css3 already cover flexbox, grid, selectors, and modern CSS features in depth, and this course won't re-teach any of that. css_intermediate_11 already previewed both BEM and utility-first thinking as two competing approaches to CSS architecture — this course picks up exactly there and goes deep on what real frameworks actually add on top.

The Problem Frameworks Actually Solve

As a CSS codebase grows across many developers and many pages, two real, recurring problems emerge. First, consistency — different developers reinventing slightly different spacing and color values, buttons that look almost-but-not-quite the same across a site. Second, naming and organization fatigue — BEM (css_intermediate_11) solves naming and scoping, but doesn't solve the "what values do I actually use" question, and doesn't prevent duplicate, near-identical CSS rules from accumulating over time.

Frameworks exist to solve these problems — not by teaching new CSS, but by providing a shared, opinionated system on top of it.

Three Genuinely Different Paradigms

Utility-first (Tailwind): compose UI directly from small, single-purpose utility classes in markup — p-4, flex, text-center. No custom CSS is written for most things; styling lives in the HTML itself.

Component frameworks (Bootstrap): complete, pre-styled, pre-built UI components — a real button, a real navbar, a real modal — ready to drop in and use with minimal customization.

Headless/unstyled (Radix UI, Headless UI): genuine UI behavior — keyboard navigation, ARIA attributes, focus management — with zero visual styling at all, meant to be styled separately using whatever approach a project already uses.

This Course's Own Roadmap

Hands-On Exercises

cssfw1-1's own roadmap pointed here. This chapter goes deep on the utility-first paradigm's own actual reasoning — and treats the classic "markup full of classes" objection honestly, rather than dismissing it.

What "Utility-First" Actually Means

Rather than writing custom CSS rules with semantic class names (css2's own BEM material — .card, .card__title), utility-first means applying many small, single-purpose classes directly to an element, each doing exactly one thing:

<div class="flex items-center p-4 bg-white rounded-lg shadow-md">

Every class maps to one CSS declaration or a tightly related small group — p-4 means padding: 1rem, flex means display: flex.

Why This Approach Exists — The Real Motivation

The naming problem: BEM makes naming consistent, but it doesn't make it easy — every new component still needs someone to invent .card, .card__header, .card__title, and hold a mental model of what CSS rules live where. Utility classes eliminate this naming step almost entirely, since the classes are already predefined, standardized, and reused everywhere.

The dead-CSS problem: with semantic classes, a project can accumulate .card-v2, .card-alt, .old-card-style rules over time that may or may not still be used anywhere — genuinely hard to know what's safe to delete. Utility classes are inherently reused across many elements, so there's no equivalent "dead" utility CSS accumulating the same way — this previews cssfw1-4's own JIT/content-scanning material directly.

Constraint as a feature: because a developer chooses from a predefined, finite set of spacing/color/sizing values (Tailwind's own design system, cssfw1-3's own material) rather than inventing arbitrary new ones each time, visual consistency across a whole team happens almost automatically, without requiring active discipline.

The Classic Objection — "My Markup Is Full of Classes"

This is a real, valid observation, not a myth to dismiss. A Tailwind-styled element's class attribute genuinely is visually noisy and long, especially compared to a single semantic class name.

The honest counter-argument, not just cheerleading: this "noise" is local — everything an element looks like is visible right there, with no need to jump to a separate stylesheet and search for a class definition, a real, genuine locality/readability trade-off, not purely a downside. And in practice, component-based frameworks (React/Vue/Svelte, per this site's own frontend framework courses) mean this "noisy" markup usually lives inside a reusable component definition written once, not repeated across every page that uses it — most real projects using Tailwind are also using a component framework, which softens the "many classes" concern considerably.

The honest remaining downside: for teams not using component-based frameworks, or for very large, deeply nested markup, this really can become genuinely harder to scan visually. This isn't a fully resolved objection — it's a real, ongoing trade-off.

A Worked Example

/* BEM (css2's own style) */
<div class="card">
  <h3 class="card__title">Product Name</h3>
</div>

.card { display: flex; align-items: center; padding: 1rem;
        background: white; border-radius: 0.5rem; box-shadow: 0 1px 3px rgba(0,0,0,.1); }
.card__title { font-weight: 600; }

/* Utility-first (Tailwind) — same visual result */
<div class="flex items-center p-4 bg-white rounded-lg shadow-md">
  <h3 class="font-semibold">Product Name</h3>
</div>

Hands-On Exercises

cssfw1-2's own utility classes weren't arbitrary — they're generated from a shared, configurable design system. This chapter covers that system directly, and ties it back to a chapter this site already has.

The Design System Underneath the Utilities

p-4, bg-white, and every other utility class from cssfw1-2 are generated from a finite set of spacing, color, and font-size values defined in a configuration file (tailwind.config.js or equivalent). This directly ties back to css_advanced_11's own token-based theming chapter — Tailwind's own config file is a real, concrete implementation of the design-token concept that chapter covered conceptually via CSS custom properties. The underlying idea is the same; the mechanism differs: Tailwind generates its own utility classes from a token set, while css_advanced_11 covered defining and using tokens directly as custom properties.

tailwind.config — Customizing the System

module.exports = {
  theme: {
    extend: {
      colors: { brand: '#1da1f2' },
      spacing: { '128': '32rem' }
    }
  }
}

theme.extend adds new values while keeping Tailwind's own sensible defaults intact; replacing a key directly under theme (without extend) discards the default scale for that key entirely. This is a real, practical distinction worth getting right — extend is almost always what a real project wants.

Arbitrary Values — The Escape Hatch

<div class="w-[327px] bg-[#1da1f2]">

Tailwind's own bracket syntax lets a developer use a one-off, non-standard value directly in a utility class, without touching the config file at all — genuinely useful for a true one-off need. Worth flagging honestly: overusing arbitrary values undermines the exact "shared, constrained design system" benefit cssfw1-2 named as one of utility-first's own real motivations. If arbitrary values show up constantly, a project has quietly opted back into inventing values ad hoc — precisely the problem the design-token system exists to prevent.

Responsive Variants

Breakpoint prefixes — md:flex, lg:grid-cols-3 — apply a utility only at a given breakpoint and above, mobile-first. This is a direct, concrete implementation of the mobile-first responsive design principle already covered conceptually elsewhere on this site (css_intermediate_07's own Responsive Design deep dive).

State Variants

hover:, focus:, disabled:, and dark: prefixes apply a utility only in a specific state or context — a genuinely elegant alternative to writing separate :hover/:focus CSS rules by hand. The dark: variant specifically addresses a real, common modern requirement (dark mode support) that's genuinely more painful to implement by hand with plain CSS custom properties alone.

Combining Variants

<button class="md:hover:bg-blue-600">

Variants stack — this applies only at the md breakpoint and above, and only on hover, combining a responsive condition and a state condition in one utility.

Hands-On Exercises

This chapter delivers directly on a promise from build-tooling1-8's own tree-shaking chapter — the same underlying principle, applied here to CSS instead of JavaScript.

The Problem — A Framework With Thousands of Possible Classes

cssfw1-3's own design system can generate an enormous number of possible utility class combinations — every spacing value, every color, every variant, every breakpoint, multiplied together. If Tailwind shipped one complete, precompiled stylesheet containing every possible class it could ever generate, that file would be enormous — genuinely impractical to ship to every user.

Content Scanning — Only Generate What's Actually Used

Tailwind's own build process scans a project's actual source files (HTML, JSX, Vue templates — configured via the content array in tailwind.config) looking for class-name strings that appear anywhere in that source code, and generates CSS only for the classes it actually finds — it never generates a giant, complete stylesheet at all. This is a plain, text-based scan, not aware of a project's actual runtime logic — Tailwind literally looks for strings matching its own class-name patterns anywhere in the specified files.

Direct Payoff of build-tooling1-8's Own Tree-Shaking Material

build-tooling1-8 explained tree shaking as "ESM's static-analysis payoff" — a JavaScript bundler analyzing which exported code is actually imported and eliminating everything else, based on static analysis of the actual source. Tailwind's own content-scanning mechanism is doing something genuinely analogous, but worth being precise about the real distinction: rather than generating everything a framework could produce and eliminating unused output afterward — closer to how PurgeCSS, Tailwind's own older, pre-JIT approach, actually worked — modern Tailwind's JIT engine flips this around and generates only what content-scanning found being used, from the start, rather than generating-then-pruning.

JIT — Just-In-Time Compilation

Modern Tailwind (v3+) compiles utility CSS on-demand, as classes are actually discovered during development, rather than the older two-step generate-everything-then-purge model. This is genuinely faster to build, and it enables things that were previously impractical at full scale — cssfw1-3's own arbitrary value syntax only works efficiently because of JIT: generating CSS for every conceivable arbitrary value upfront would be effectively infinite, but generating it on-demand, only when actually encountered in source, is entirely tractable.

Why the content Array Has to Be Configured Correctly

A real, practical, honest gotcha: if a project's content array doesn't correctly include every file or pattern where Tailwind classes actually appear, classes used in an un-scanned file will silently never be generated — the utility class simply won't work in production. This is a genuinely common, real practical mistake.

Hands-On Exercises

Four chapters covered utility-first CSS in depth. This chapter turns to a genuinely different, older, still-widely-used paradigm — with the same honest, two-sided treatment this course has applied throughout.

A Genuinely Different Model

Rather than composing a design from small primitives (cssfw1-2's own utility-first material), Bootstrap ships complete, pre-styled, pre-built components — a real button (.btn .btn-primary), a real navbar, a real modal, a real grid system — all ready to drop into markup and use immediately, with a finished, coherent visual design already applied.

A Brief, Honest History

Bootstrap predates Tailwind's own utility-first approach by several years — originally released by Twitter in 2011, and historically the dominant CSS framework for a long stretch of the 2010s, before utility-first approaches became more common in newer projects. Worth naming honestly as real historical context, not as a reason to dismiss Bootstrap's own continued relevance — it remains very widely used, especially for internal tools, admin panels, rapid prototypes, and in organizations without dedicated design resources.

The Real Speed Advantage

Building a working, reasonably polished-looking form, navbar, and modal with Bootstrap can take minutes, since the actual visual design work has already been done by Bootstrap's own team. This is a genuinely real, honest advantage for a team without dedicated design resources, an internal tool, a rapid prototype, or a genuinely time-constrained project — not a lesser approach, but one optimizing for a different priority (speed and completeness) than utility-first's own priority (design flexibility).

The Real "Everything Looks the Same" Critique

Also genuinely real and worth taking seriously, not dismissing: because so many sites and projects use Bootstrap's own default theme with minimal customization, a recognizable "Bootstrap look" became genuinely, visibly common across the web — a real, documented criticism, not an exaggerated myth.

An honest nuance, though: this isn't actually an inherent technical limitation of Bootstrap itself. Bootstrap is genuinely customizable (its own Sass variables and theming system, covered next) — the "everything looks the same" problem is really a consequence of how many projects use Bootstrap's own defaults without customizing them, a real, common practice pattern rather than a hard capability limitation. The criticism is valid as an observation about common practice; it's somewhat imprecise as a claim about what Bootstrap itself can or can't do.

Customization — Sass Variables & Theming

// Override before compiling Bootstrap's own Sass
$primary: #1da1f2;
$border-radius: 0.75rem;

@import "bootstrap/scss/bootstrap";

Bootstrap's own Sass source lets a project override core design variables before compiling, genuinely changing the visual output while keeping the same component structure and behavior — a real customization mechanism that does exist, even though it's less commonly exercised than it could be, tying directly back to the honest nuance above.

JavaScript-Dependent Components

Worth naming honestly: several Bootstrap components — modals, dropdowns, carousels, tooltips — require Bootstrap's own bundled JavaScript to actually function (open/close/toggle behavior). Bootstrap isn't purely a CSS framework the way Tailwind is; adopting it is a decision with real JavaScript-dependency implications, not just a styling decision. This previews cssfw1-6's own headless-library material, which handles interactive behavior in a genuinely different, more flexible way.

When Bootstrap Genuinely Makes Sense

Internal tools and admin panels, rapid prototypes, teams without dedicated design or frontend resources, and projects where "looks like Bootstrap" is a genuinely acceptable trade-off for development speed.

Hands-On Exercises

cssfw1-1's own third paradigm gets its full treatment here — and it connects directly to a chapter this site already has.

A Third, Structurally Different Paradigm

Utility-first provides styling primitives (cssfw1-2); component frameworks provide complete, finished designs (cssfw1-5). Headless libraries provide neither — they provide only behavior, with literally zero visual styling shipped at all.

What "Headless" Actually Means Here

Worth a brief clarifying note, since "headless" is used in other contexts too (a headless CMS, for instance): here it specifically means a component's own interactive logic — state management, keyboard handling, focus management, ARIA attribute wiring — is fully implemented and provided, but rendered with zero default CSS or visual opinion at all. A headless dropdown menu is fully functional and fully accessible, with no visual appearance whatsoever until it's styled.

Why This Exists — The Real Problem It Solves

Building a genuinely accessible interactive component — a dropdown, a modal, a combobox — correctly is genuinely hard. Real keyboard navigation (arrow keys, Escape, Tab trapping), correct ARIA roles/states/properties, and correct focus management are all easy to get subtly wrong — web-accessibility1's own material already established just how much genuine expertise this requires.

Headless libraries exist specifically to let a team not have to solve this hard problem themselves, while still having complete freedom over visual design — exactly the gap both Tailwind (styling only, no complex interactive behavior built in) and Bootstrap (styling and behavior bundled together, less visual flexibility, per cssfw1-5) leave open.

A Concrete Example — A Dropdown Primitive

<DropdownMenu.Root>
  <DropdownMenu.Trigger className="px-4 py-2 bg-blue-600 text-white rounded">
    Options
  </DropdownMenu.Trigger>
  <DropdownMenu.Content className="bg-white shadow-lg rounded p-1">
    <DropdownMenu.Item className="px-3 py-2 hover:bg-gray-100">Edit</DropdownMenu.Item>
    <DropdownMenu.Item className="px-3 py-2 hover:bg-gray-100">Delete</DropdownMenu.Item>
  </DropdownMenu.Content>
</DropdownMenu.Root>

The Root/Trigger/Content/Item sub-components provide full keyboard navigation, ARIA wiring, and focus-trap behavior automatically — the developer supplies 100% of the visual styling, commonly via Tailwind utility classes (cssfw1-2's own material), a natural, common real pairing that directly previews cssfw1-7's own material.

Tying Directly to web-accessibility1's Own ARIA Material

web-accessibility1 covered ARIA's own first rule (don't use ARIA if a native element already provides the behavior or semantics needed) and the real cost of ARIA misuse being worse than no ARIA at all. Headless libraries are, in essence, professionally-built, thoroughly-tested implementations of exactly the ARIA patterns that chapter warned are easy to get wrong. Using a well-maintained headless library is, in a real sense, outsourcing the hardest, highest-stakes part of web-accessibility1's own material to a library specifically built and tested for that purpose — rather than every team independently reimplementing (and potentially getting wrong) the same accessible dropdown/modal/combobox pattern from scratch.

An honest nuance worth naming explicitly: this isn't a substitute for actually understanding accessibility. web-accessibility1's own material remains essential for knowing whether a given headless component is being used and configured correctly, and for anything the library doesn't cover — the same "don't skip the fundamentals" discipline cssfw1-1's own warn-box established for CSS itself.

The Trade-off — More Setup, More Control

Headless libraries require more initial work than Bootstrap's own drop-in components — there's no finished visual design at all; everything must be styled. But they require genuinely less work than building the same accessible behavior completely from scratch by hand. A real middle ground between cssfw1-5's own "fast but visually generic" and "fully custom, but the developer owns 100% of the accessibility risk."

Hands-On Exercises

cssfw1-6 closed with a direct preview of this chapter — a genuinely novel distribution model built entirely around combining two paradigms this course already covered.

The Traditional npm Dependency Model, Briefly Recapped

Normally, using a component library — Bootstrap, or a headless library like cssfw1-6's own Radix — means installing it as a normal npm dependency. The component's own source code lives inside node_modules, is treated as external, third-party code, and is updated by bumping a version number. The developer never directly edits the library's own source.

shadcn/ui's Genuinely Different Model

Rather than installing shadcn/ui as a dependency, its own CLI tool copies the actual component source code — built on cssfw1-6's own headless primitives, styled with cssfw1-2's own Tailwind utilities — directly into the project's own codebase. The component becomes literal, owned, editable project code, not an external dependency at all.

npx shadcn-ui add button

This generates an actual button.tsx file directly in the project's own components folder — from that point forward, that file is the project's own code, indistinguishable from anything hand-written.

Why This Is a Genuinely Novel Architectural Choice

In the traditional dependency model, updates are easy — bump a version — but customization beyond what the library's own API exposes is hard, often impossible without forking or fighting the library's own abstractions. shadcn/ui's own owned-code model is the exact reverse trade-off: customization is trivial (it's just a project's own code, edited however desired, no API to fight), but "updates" don't really exist in the traditional sense — if the upstream shadcn/ui component improves, there's no npm update command; a team has to manually notice and reapply changes to their own already-copied, already-customized version themselves. This is a genuine, deliberate trade-off, not simply an improvement over the traditional model.

How the Three Pieces Combine

Why This Model Emerged

A genuine, documented response to real frustration with traditional component libraries specifically around customization friction — cssfw1-5's own "everything looks the same" critique, and the broader "fighting a library's own limited prop API to achieve a design that's 90% but not 100% what a component library provides out of the box" problem. shadcn/ui's own real innovation isn't the individual pieces — headless behavior and Tailwind styling both already existed separately — it's the distribution model itself.

The Real Trade-offs, Honestly

Upside: complete design freedom (it's just a project's own code), no version-lock-in anxiety, no fighting a component API's limited customization props. Downside: no automatic security or bug-fix updates the way a real npm dependency provides — a genuine, real, security-relevant concern, distinct from the customization discussion.

Hands-On Exercises

This chapter covers a fourth real pattern this course hasn't touched yet — and gives it the same honest, two-sided treatment applied throughout, rather than ignoring it or dismissing it.

What CSS-in-JS Actually Is

const Button = styled.button`
  background: blue;
  padding: 1rem;
`;

CSS-in-JS means writing actual CSS rules directly inside JavaScript or component files (styled-components, Emotion) — a component's own styling lives literally alongside its own logic in the same file, generated at runtime by a library that dynamically creates and injects real <style> rules into the page as components render. This looks like writing plain CSS, but it's actually a JavaScript template literal being processed by a library.

Why This Was Genuinely Popular — The Real Motivations

Worth being fair and honest here: CSS-in-JS wasn't a bad idea everyone was fooled by. It solved real problems when it became popular, in the mid-to-late 2010s alongside React's own rise. True component-scoped styles with no risk of global CSS collision at all — a genuinely stronger guarantee than BEM's own naming-convention-based scoping, since it's enforced by the tooling itself rather than developer discipline. And dynamic styling based on component props or state felt genuinely natural (background: ${props => props.primary ? 'blue' : 'gray'}), since styles and logic already lived in the same file and language. For a real period, this was considered a genuinely leading-edge, sophisticated approach — not a mistake.

The Real, Documented Reasons for Its Decline

The central, real technical reason is runtime cost. Classic CSS-in-JS libraries generate and inject styles at runtime, in the browser, as components render — a genuine, measurable JavaScript execution cost, and a genuine risk of a delay before styles are actually applied (a real, documented "flash of unstyled content" in some setups). This is a direct, structural contrast with every other paradigm this course has covered: Tailwind's own JIT (cssfw1-4) generates CSS at build time, Bootstrap ships precompiled CSS, headless libraries (cssfw1-6) ship zero styles at all. Classic CSS-in-JS is genuinely the only paradigm in this entire course that does real styling work in the browser, at runtime, rather than ahead of time.

"Zero-runtime" CSS-in-JS successor tools (vanilla-extract, some newer Emotion configurations) emerged specifically to fix this — extracting styles to real, static CSS at build time instead, closing the exact gap. Worth an honest, dated note: the CSS-in-JS story itself evolved once this problem became well understood, rather than the entire idea being abandoned outright.

The Shift Toward Utility-First / Zero-Runtime Approaches

Tailwind's own real rise (cssfw1-2 through cssfw1-4) is directly connected to this exact runtime-cost critique of classic CSS-in-JS. Tailwind offers component-scoped-feeling styling — via co-located utility classes in markup — with build-time, not runtime, CSS generation, genuinely addressing the same original motivation (avoiding global CSS collision, styles living near component logic) that CSS-in-JS was solving, without its real runtime cost. This is the actual, documented reason for the broader industry shift, not simply changing fashion.

Is CSS-in-JS "Dead"? An Honest, Precise Answer

No, not entirely. It's still genuinely used in real, existing production codebases — a real, ongoing migration-cost consideration for teams that adopted it early, not something to casually rip out. Newer, genuinely zero-runtime variants remain a real, legitimate option for teams that specifically want CSS-in-JS's own dynamic-styling ergonomics without its classic runtime cost. "Declining in new project adoption" is the precise, honest claim — not "nobody uses this anymore."

Hands-On Exercises

This is this course's own central chapter — where eight chapters of paradigms, trade-offs, and honest critiques become one usable decision framework.

The Four Paradigms, One More Time

Factor 1 — Team CSS/Design Expertise

A team with genuine CSS depth or dedicated design resources can make good use of utility-first's own flexibility, or a headless-plus-custom-styling combination. A team without dedicated design resources or deep CSS comfort benefits more from Bootstrap's own finished, professionally-designed components — directly echoing cssfw1-5's own "when Bootstrap genuinely makes sense" material.

Factor 2 — Design-System Maturity

An early-stage project with no established design system often benefits from Bootstrap's own built-in design system, or from committing early to Tailwind's own config-driven token system (cssfw1-3) as the seed of a genuine, from-scratch design system. A mature product with an already-established, unique brand identity is exactly where utility-first's own full flexibility, or a headless-plus-custom-Tailwind combination, pays off most — a generic component-framework look becomes a real liability once a brand identity already exists, per cssfw1-5's own "everything looks the same" critique.

Factor 3 — Performance/Bundle-Size Needs

A performance-critical application should specifically avoid classic, runtime CSS-in-JS — cssfw1-8's own central technical finding. Tailwind's own JIT-generated, purged CSS (cssfw1-4) and headless libraries' own typically small runtime footprint are both genuinely strong choices here. Bootstrap's own bundle size is a real, if less dramatic, consideration too — shipping a complete framework's CSS and JS even when only a fraction of components are actually used, unless a project does its own manual Sass-based selective import, which most don't bother doing in practice.

Factor 4 — Accessibility Requirements

An application with genuinely serious, non-negotiable accessibility requirements — a public-sector site, an enterprise product with compliance obligations — benefits enormously from headless libraries' own professionally-built, tested ARIA/keyboard/focus implementations (cssfw1-6). Rolling custom interactive components using pure Tailwind utilities, without a headless library underneath, means the team owns 100% of cssfw1-6's own described accessibility risk themselves — a real, concrete factor that should weigh heavily toward the headless-plus-Tailwind approach for accessibility-critical projects specifically.

A Practical Decision Framework

1. Does the team have deep CSS/design expertise, or need a fast, complete, pre-designed starting point? (Pre-designed need → Bootstrap; expertise/flexibility wanted → Tailwind or headless+Tailwind.)
2. Is there already an established, unique brand/design system, or is one still being defined? (Established → utility-first/headless for full control; undefined/early → Bootstrap or Tailwind's own token system as a starting point.)
3. Is runtime performance/bundle size a serious, measured concern? (Yes → avoid classic CSS-in-JS specifically.)
4. Are there genuinely serious, non-negotiable accessibility requirements? (Yes → strongly favor headless libraries over hand-rolled interactive components.)
5. Combining paradigms is normal, not a compromise — Tailwind for styling plus a headless library for complex interactive components is a genuinely common, sensible combination, not a failure to fully commit to one approach.

The Honest Middle Ground

Not every decision has one clean answer. Most real projects genuinely combine pieces of multiple paradigms rather than picking exactly one — that's the normal, sensible outcome, not a sign of an unclear decision.

Hands-On Exercises

Nine chapters covered four paradigms in depth, closing with a real decision framework. This capstone makes that framework tangible — building the exact same component three genuinely different ways.

The Scenario

One real component: an accessible dropdown/select menu ("Choose a category"). Simple enough to build three ways concisely, but complex enough to actually exercise real accessibility concerns — keyboard navigation, ARIA state, focus management — exactly the kind of component cssfw1-1 named as the real test case for comparing paradigms.

Approach 1 — Vanilla CSS + BEM

Per css_intermediate_11's own BEM precedent — real HTML, real hand-written CSS, and real hand-written JavaScript for every piece of interactive behavior:

<div class="dropdown">
  <button class="dropdown__trigger" aria-haspopup="listbox" aria-expanded="false" id="dropdown-trigger">
    Choose a category
  </button>
  <ul class="dropdown__menu" role="listbox" aria-labelledby="dropdown-trigger" hidden>
    <li class="dropdown__item" role="option" tabindex="-1">Electronics</li>
    <li class="dropdown__item" role="option" tabindex="-1">Home Goods</li>
    <li class="dropdown__item" role="option" tabindex="-1">Books</li>
  </ul>
</div>

.dropdown { position: relative; display: inline-block; }
.dropdown__trigger { padding: .5rem 1rem; border: 1px solid #ccc; border-radius: .375rem; background: #fff; }
.dropdown__menu { position: absolute; top: 100%; left: 0; margin-top: .25rem; background: #fff;
  border: 1px solid #ccc; border-radius: .375rem; box-shadow: 0 2px 8px rgba(0,0,0,.1); list-style: none; padding: .25rem 0; min-width: 100%; }
.dropdown__item { padding: .5rem 1rem; cursor: pointer; }
.dropdown__item:hover, .dropdown__item:focus { background: #f3f4f6; }

// Real, hand-written interactive behavior — keyboard nav, focus, ARIA state
const trigger = document.getElementById('dropdown-trigger');
const menu = trigger.nextElementSibling;
const items = menu.querySelectorAll('.dropdown__item');
let activeIndex = -1;

trigger.addEventListener('click', toggleMenu);
trigger.addEventListener('keydown', e => {
  if (e.key === 'ArrowDown' || e.key === 'Enter') { e.preventDefault(); openMenu(); items[0].focus(); activeIndex = 0; }
});
document.addEventListener('click', e => {
  if (!trigger.contains(e.target) && !menu.contains(e.target)) closeMenu();
});
items.forEach((item, i) => {
  item.addEventListener('keydown', e => {
    if (e.key === 'ArrowDown') { e.preventDefault(); activeIndex = (i + 1) % items.length; items[activeIndex].focus(); }
    if (e.key === 'ArrowUp') { e.preventDefault(); activeIndex = (i - 1 + items.length) % items.length; items[activeIndex].focus(); }
    if (e.key === 'Escape') { closeMenu(); trigger.focus(); }
    if (e.key === 'Enter' || e.key === ' ') selectItem(item);
  });
  item.addEventListener('click', () => selectItem(item));
});
function toggleMenu() { menu.hidden ? openMenu() : closeMenu(); }
function openMenu() { menu.hidden = false; trigger.setAttribute('aria-expanded', 'true'); }
function closeMenu() { menu.hidden = true; trigger.setAttribute('aria-expanded', 'false'); }
function selectItem(item) { trigger.textContent = item.textContent; closeMenu(); trigger.focus(); }

This is cssfw1-6's own "you own 100% of the accessibility risk yourself" case, made concrete — a genuinely real amount of code, not a toy example.

Approach 2 — Pure Tailwind Utilities

The same structure, styled entirely with Tailwind utility classes (cssfw1-2's own material) instead of BEM and custom CSS:

<div class="relative inline-block">
  <button class="px-4 py-2 border border-gray-300 rounded-md bg-white" aria-haspopup="listbox" aria-expanded="false" id="dropdown-trigger-tw">
    Choose a category
  </button>
  <ul class="absolute top-full left-0 mt-1 bg-white border border-gray-300 rounded-md shadow-lg list-none py-1 min-w-full" role="listbox" aria-labelledby="dropdown-trigger-tw" hidden>
    <li class="px-4 py-2 cursor-pointer hover:bg-gray-100" role="option" tabindex="-1">Electronics</li>
    <li class="px-4 py-2 cursor-pointer hover:bg-gray-100" role="option" tabindex="-1">Home Goods</li>
    <li class="px-4 py-2 cursor-pointer hover:bg-gray-100" role="option" tabindex="-1">Books</li>
  </ul>
</div>

// The exact same hand-written JavaScript from Approach 1, unchanged

Critically, the interactive behavior JavaScript is identical to Approach 1 — pure Tailwind (cssfw1-2 through cssfw1-4) is only a styling solution. Switching from BEM to Tailwind changes how the component looks; it removes none of the accessibility-implementation burden at all.

Approach 3 — Headless Primitive + Tailwind

cssfw1-6's own headless primitive, styled with the exact same Tailwind utilities as Approach 2:

<DropdownMenu.Root>
  <DropdownMenu.Trigger className="px-4 py-2 border border-gray-300 rounded-md bg-white">
    Choose a category
  </DropdownMenu.Trigger>
  <DropdownMenu.Content className="bg-white border border-gray-300 rounded-md shadow-lg py-1">
    <DropdownMenu.Item className="px-4 py-2 cursor-pointer hover:bg-gray-100 outline-none">Electronics</DropdownMenu.Item>
    <DropdownMenu.Item className="px-4 py-2 cursor-pointer hover:bg-gray-100 outline-none">Home Goods</DropdownMenu.Item>
    <DropdownMenu.Item className="px-4 py-2 cursor-pointer hover:bg-gray-100 outline-none">Books</DropdownMenu.Item>
  </DropdownMenu.Content>
</DropdownMenu.Root>

// No hand-written interactive-behavior JavaScript at all

Every line of hand-written keyboard/focus/ARIA logic from Approaches 1 and 2 is gone entirely — replaced by a professionally-built, tested implementation. This is cssfw1-6's and cssfw1-7's own real payoff, demonstrated concretely rather than described abstractly.

Side-by-Side Comparison

Why This Comparison Matters

Approach 1 vs. Approach 2 is entirely about the styling mechanism — identical behavior code, different CSS approach. Approach 3 changes a genuinely different axis altogether — who owns the behavior and accessibility implementation, not just how something looks. This is exactly why cssfw1-1's own paradigm framing treated headless libraries as a structurally different kind of choice, not simply "styling approach #3."

Chapter Attribution

Hands-On Exercises