Wes Bos Sick Picks

---
name: wes-bos-sick-picks
description: Research-first workflow for building frontend UI components (any framework), in the spirit of Wes Bos. Use when designing or implementing a UI component, layout, interaction, or CSS/HTML feature and you want a modern, accessible, best-practice solution rather than a first guess. Researches pitfalls and platform capabilities BEFORE planning, designs for WCAG accessibility using modern web standards, then verifies the approach against what Wes Bos has said on X plus trusted sources (MDN, web.dev, CSS-Tricks, Smashing, Frontend Masters, etc.). Named after the Syntax "Sick Picks" segment — because the job is to pick the sickest modern approach.
---

# Wes Bos Sick Picks — research-first, accessible, modern frontend work

Build frontend the way you'd build it after reading the current best thinking — not from memory. The platform moves fast; what was "roll your own with JS" two years ago is often "one native element + a few lines of CSS" today. This skill front-loads research so the plan is right before any code is written, bakes in accessibility, and cross-checks the chosen approach against trusted voices (Wes Bos chief among them) before committing. The goal each time: **pick the sickest modern approach** — and prove it's the right call.

Use it for: new components (modal/dialog, drawer, popover, tabs, tooltip, accordion, combobox, carousel…), layout/animation/interaction work, or any "what's the right modern way to do X in HTML/CSS/JS" question. It is **framework-agnostic** — adapt the output to the project's stack and conventions (React, Vue, Svelte, Angular, web components, or plain HTML).

> ⚠️ Do this research **before** you write the plan or any code. The whole point is to discover the modern/native primitive and its pitfalls up front, so you don't plan around an outdated approach.

## The workflow

### 1. Understand the request and the codebase (explore first)
- Restate what's being built and pin down the real requirements (responsive behavior, breakpoints, content, interactions, states).
- Search the codebase for **existing patterns to reuse** before proposing anything new: design-system primitives, styling utilities, transition/animation conventions, a11y helpers (focus, ids, keyboard), i18n, breakpoint detection, icon usage, and how similar components are already built. Reuse beats reinvention.
- If a sibling component already solves part of the problem (e.g. an existing popover/dialog), study how it handles open/close, transitions, focus, and scroll. Match those conventions.

### 2. Research pitfalls and the modern approach (the core of this skill)
Run web searches **before planning**. Goal: find the current-best, ideally native, approach and the gotchas that bite people.

Search in this order, adapting the topic:
- `"<feature> modern best practices <current year>"` — e.g. `accessible drawer dialog element 2026 best practices`
- `"<feature> accessibility WCAG pitfalls"` — focus management, keyboard, screen readers, ARIA.
- `"<native element/API> <feature>"` — is there a native primitive? (`<dialog>`, `<details>`, popover API, `<selectlist>`/`<selectedcontent>`, anchor positioning, `inert`, `command`/`commandfor` invokers…)
- `"<feature> CSS animation @starting-style allow-discrete transition-behavior"` — modern transitions for top-layer / `display:none` elements.
- Browser-support / baseline check for anything new (`caniuse` / Baseline status). Decide: ship it, progressively enhance, or polyfill.

Then **fetch the 2–3 most relevant articles** (WebFetch) to extract concrete code, the exact CSS, and the named pitfalls — don't stop at search snippets.

Capture, in your own notes: the recommended approach, what it gives you for free, the known pitfalls, and the browser-support caveats.

### 3. Design for accessibility (WCAG) from the start
Accessibility is a design input, not a later pass. Prefer native semantics that hand you correct behavior for free, then fill the gaps:
- **Semantics first** — use the right element (`<dialog>`, `<button>`, `<nav>`, headings, lists). Native elements come with roles, keyboard behavior, and focus handling.
- **Name every control and region** — `aria-label` / `aria-labelledby` (link region to its visible title), `aria-describedby` where useful. Reuse the project's i18n for labels; never hard-code if the repo localizes.
- **Keyboard** — everything operable without a mouse: `Tab` order, `Enter`/`Space`, `Escape` to dismiss, arrow keys where the pattern expects them (tabs, menus, listboxes). Visible `:focus-visible` styling.
- **Focus management** — move focus into the new context, trap it while open (native modal `<dialog>` does this for you), and restore it to the trigger on close.
- **State exposure** — `aria-expanded`, `aria-selected`, `aria-current`, `aria-modal`, `aria-live` for dynamic updates.
- **Respect user preferences** — `prefers-reduced-motion` (disable/replace motion), and don't trap scroll or break zoom.
- Sanity-check against the relevant WAI-ARIA Authoring Practices pattern, but lean on native behavior over reimplementing it.

### 4. Use modern HTML/CSS and platform features
Reach for the platform before reaching for JS or a library:
- Native elements/APIs: `<dialog>` + `showModal()`, popover API, `<details>/<summary>`, `inert`, `command`/`commandfor` invokers, CSS anchor positioning, `:has()`, container queries, `scrollbar-gutter`, `text-wrap: balance/pretty`, view transitions.
- Modern transitions for entering/exiting top-layer & `display:none` elements: `@starting-style`, `transition-behavior: allow-discrete`, transitioning `display`/`overlay`.
- Logical properties, `dvh`/`svh` units, modern color/spacing tokens — match whatever the project's styling system already uses (Tailwind, CSS modules, vanilla, etc.).
- Only add a dependency or hand-rolled JS when the platform genuinely can't do it, or browser support forces a fallback. Note the trade-off when you do.

### 5. Verify the approach against Wes Bos + trusted sources
Before finalizing the plan, confirm the chosen approach against external authorities — this is the "would Wes Bos do it this way?" gate.
- **Wes Bos on X / wesbos.com** — search e.g. `wesbos twitter x.com <feature> <native element>` or `wesbos tips <feature>`. He frequently posts sharp takes and gotchas on native HTML/CSS (dialog modality requiring `.showModal()`, `@starting-style` + `allow-discrete`, popover API, etc.). Cite the specific post.
- **Trusted sources** (allowlist below) — confirm the pattern, the a11y details, and the pitfalls line up. If sources disagree, prefer the most recent + the most authoritative (MDN/web.dev/spec), and say so.
- If verification contradicts the draft approach, **revise before planning further** — that's the skill working.

Trusted source allowlist (prefer these; recency matters):
- MDN Web Docs (`developer.mozilla.org`), web.dev / Chrome for Developers
- CSS-Tricks, Smashing Magazine, Frontend Masters blog
- WAI-ARIA Authoring Practices (`w3.org/WAI/ARIA/apg`), A11Y Project
- Practitioners: Wes Bos, Josh Comeau, Kevin Powell, Adam Argyle (nerdy.dev), Una Kravets, Stephanie Eckles (Modern CSS), Ahmad Shadeed
- Baseline / caniuse for support status

### 6. Plan, then implement
- Write the plan with a short **Context** (problem + outcome), the **recommended approach only** (native primitive + the specific modern CSS), the **a11y checklist** for this component, files to create/modify (reusing the patterns found in step 1), and a **verification** section.
- Include a **Research notes / sources** list with links — including the specific Wes Bos post(s) and the trusted sources that confirmed the approach. This is non-negotiable: the plan must show its work.
- Implement matching the project's conventions (SFC/JSX order, styling system, naming, i18n, testing, stories). Don't introduce a new styling or state pattern when one exists.

### 7. Verify the solution
- Run the project's linter/formatter and tests.
- Add/adjust tests and (if the project has them) component stories / visual snapshots.
- Manually validate accessibility: keyboard-only operation, focus trap + restore, `Escape`/dismiss, screen-reader announcement of the accessible name, and reduced-motion behavior.
- Confirm browser-support assumptions hold for the project's support matrix; note any progressive-enhancement fallback.

## Guardrails
- **Research before planning.** No plan or code until steps 2 and 5 are done and the approach is verified.
- **Native and accessible by default.** Justify any non-native or inaccessible shortcut explicitly.
- **Reuse over reinvention.** Prefer the codebase's existing primitives and conventions.
- **Cite your sources**, especially the Wes Bos verification and at least one other trusted source, in the plan.
- **Framework-agnostic.** Keep the *approach* portable; only the final implementation is stack-specific.