Use these CSS features instead of JavaScript

Summary of CSS features replacing (or reducing) JavaScript

1) Smooth scrolling without manual offsets

• Problem: scroll-behavior: smooth plus anchor/section jumping can cause the target to be hidden/overlapped by a fixed header.
• CSS solution: use scroll-margin on the target (e.g., the section or the header element that corresponds to the target ID) so the browser accounts for spacing automatically.
• Demo detail: using a viewport-relative scroll-margin (e.g., vw/vh) helps illustrate spacing differences when scrolling to “middle” vs “bottom”.
• Accessibility: coordinate smooth scrolling with prefers-reduced-motion so users who prefer reduced motion get instant jumps (while still benefiting from scroll-margin).
• Support note: described as having solid browser support for scroll-behavior, and “around forever” / widely available support for scroll-margin.

2) Horizontal scrolling + CSS scroll snapping

• Approach: create a horizontal scroller (shown using CSS Grid, though flexbox also works) and rely on CSS scroll snapping.
• Key CSS requirements for snap:
  • Parent: define scroll-snap-type (axis + snapping mode).
  • Child: define scroll-snap-align (the snap alignment target like center, left, right, etc.).
• scroll-snap-type values:
  • Axis: inline/block (or x/y)
  • Mode: mandatory vs proximity (recommended to test based on your use case)
• UX notes:
  • Desktop: snapping can feel less ideal during scrolling, but it still snaps reliably to the next element.
  • Mobile: described as feeling “just great” for web app-like horizontal content.
• Support note: described as excellent.

3) Form validation: prefer CSS :user-valid / :user-invalid over JS blur logic

• Motivation: common JS patterns (listening to blur, toggling “touched”, then applying valid/invalid styles) can become complex.
• Why CSS-only :valid/:invalid can be a poor UX:
  • Fields may be marked invalid immediately based on constraints, even before the user interacts (e.g., required fields appear invalid on load).
• CSS solution: use :user-valid and :user-invalid so validation styling changes only after user interaction (e.g., after focus/blur).
• Examples mentioned:
  • Required fields can become invalid once constraints apply, but remain neutral until the user types.
  • Use built-in constraints like minimum length to trigger valid/invalid states automatically.
  • Use pattern with regular expressions to validate formats (e.g., requiring a number).
• Messages:
  • Browser-native validation messages can be customized/extended (customization typically requires JS), but the base validity marking can work without it.
• Recommendation / best practice:
  • Use CSS as the first line of defense for user feedback.
  • Still perform server-side validation on submit.
• Support note: discussed as broadly available for a couple of years; “safe at this stage,” with the reminder to re-check depending on the audience.

4) Better focus styling: use :focus-visible instead of removing outlines

• Issue: removing focus outlines (e.g., outline: none / focus: 0) hurts accessibility for keyboard users.
• CSS solution: use :focus-visible so the focus ring appears only when appropriate (e.g., keyboard/tab navigation), but not for mouse clicks.
• Support note: described as standard browser behavior with strong support.

5) Textarea sizing without “magic numbers”: lh unit + min height

• Problem: “make it 3 lines tall” often becomes fragile when fonts change—hard-coded heights break.
• CSS solution:
  • Use the lh unit to size textarea height in terms of “number of lines” (e.g., min-height: 3lh).
  • Prefer min-height (and possibly logical property variants like min-block-size) over fixed height.
• Result: textarea height adjusts automatically when the font size changes, maintaining the intended line count.

6) Auto-growing fields/textarea: field-sizing

• Previous pain: expanding textarea as the user types typically required JS measuring.
• CSS solution: field-sizing enables auto-growing behavior via a single CSS property.
• Progressive enhancement:
  • Described as broadly available, with full support for most browsers after it was added “recently”.
  • Used as a strong example of progressive enhancement for chat bubbles and other content-dependent sizing.

Main speakers / sources

• Kevin Powell (the channel host referenced throughout: “Kevin Powell” / “I’ll leave a link in the description” / “I have to talk about… it might be worth…”).
• Mentions of inspiration/support: Johnny (credited as inspiration), plus “patrons and sponsors” supporting the channel.