Native select dropdowns gain real CSS customization via appearance: base-select

Native dropdowns finally accept real CSS

For most of the web's history, the select element has resisted styling. Its popup and internal parts were often drawn by the operating system, and appearance: none removed only some of the default look. Teams that needed a dropdown matching their design system ended up rebuilding the control in JavaScript — and inheriting the keyboard handling, focus management and accessibility work that came with it. According to a dev.to walkthrough published on 22 September 2026, the platform now has an answer: a new appearance: base-select value that makes the native control customizable with plain CSS while keeping built-in selection and form submission intact.

One CSS value opts in both parts

The feature extends the existing element rather than replacing it. You apply appearance: base-select to the select itself and to its popup through the ::picker(select) pseudo-element. Once opted in, several new styling hooks become available: ::picker-icon targets the arrow, option::checkmark styles the selection marker, option:checked matches the currently chosen item, and the :open pseudo-class reflects whether the popup is expanded.

The dev.to article recommends wrapping these rules in an @supports (appearance: base-select) block. Browsers without the feature then simply render an ordinary, unstyled but fully functional select.

Rich markup inside options

Options can also hold richer HTML than plain text. The article's example is a color picker where each option contains a circular swatch plus a text label. An optional button as the first child of the select, containing a selectedcontent element, shows a clone of the selected option's content in the closed control — choosing 'Mint' updates both the swatch and the label displayed on the button. Explicit value attributes keep submitted data predictable, and decorative swatches are hidden from assistive technology so each option still has a readable name.

Support is not Baseline yet

As of the author's check on 22 September 2026, the single-selection features described are not yet Baseline, so the recommendation is to treat them as progressive enhancement. The screenshots in the article come from Chromium 153.0.8010.0, and Safari 27 reportedly ships different base styles, meaning unstyled defaults should not be expected to look identical across engines.

Practical caveats

Two integration risks are flagged:

• On touch devices, an opted-in picker stays inside the browser viewport and replaces the operating system's usual picker, so mobile testing is essential.
• Rich select markup can expose parser bugs or SSR hydration problems in frameworks. The article advises testing your framework and assistive-technology combinations, treating native semantics as a foundation rather than a substitute for testing.

It also suggests keeping readable text in every option even when adding icons or images, using a proper label, keeping keyboard focus visible, and leaving option content non-interactive.

Why it matters

The select dropdown is one of the most frequently rebuilt native components on the web, and hand-rolled replacements are a recurring source of accessibility bugs. Moving the styling layer into the platform itself lets developers keep native semantics, keyboard behavior and form integration while matching a design system — potentially retiring a whole category of JavaScript widgets. The trade-off is a transitional period of uneven browser support and differing default styles, which makes @supports guards and real device testing the price of admission.