The depth hiding inside a “simple” split button

Adam Argyle’s GUI Challenges series on web.dev keeps turning out components that look trivial at first glance—and then reveal how much real front-end craft goes into them. The split-button component is a good example. On the surface it’s just a button with an attached menu. But the accompanying write-up walks through a long list of concerns that are easy to miss when you’re only checking that something “works and looks right.”

A few of the details worth calling out:

  • Color is engineered, not picked. The palette uses custom properties to define what is essentially a menu of color combinations. Dark shades are derived from the base colors rather than falling back to black, which keeps the whole set feeling cohesive. The setup is also designed to support theming without a rewrite.
  • Shadows respect the theme. Because the component supports multiple themes, the shadow values are chosen so they don’t invert awkwardly—no light shadows on dark backgrounds, no dark-on-dark depth that disappears.
  • SVG strokes do heavy lifting. Using strokes instead of filled shapes keeps the icons flexible and opens up CSS-controlled options like rounding the line caps.
  • Interaction states increase contrast. Active and hover states are deliberately built to raise contrast rather than dim or muddy it.
  • Keyboard and assistive tech are first-class. The menu opens when tabbed to, arrow keys move focus through the items, and visual feedback follows. VoiceOver testing verified flows like pressing ESC to close the menu and pull focus away cleanly.
  • Reduced motion is honored. When the user prefers less motion, the open/close animation is toned down.
  • CSS stays lean. The only thing that visually opens and closes the menu is :focus-within. ARIA state, however, is still updated via JavaScript so the semantics match what the user sees.

That list isn’t even exhaustive. The full article digs into inspection tooling and small helper libraries used during the build. The takeaway: even something as small as “a button with a menu” carries a wide surface area of requirements, and each one has real consequences for users when it’s done wrong.

If you enjoy this kind of exercise, CodePen also runs a weekly challenge prompt with ideas and resources. A big part of the appeal is that other people are building along with you, so you get to compare how different folks approached the same prompt.