The humble HTML <select> has been one of the most stubbornly un‑stylable elements on the web. For decades, developers resorted to JavaScript‑driven custom dropdowns, sacrificing native behavior and accessibility just to get consistent styling across browsers and platforms. That trade‑off has been both painful and expensive in terms of maintenance, performance, and UX bugs.
In 2025, 2026, that story finally started to change. Chrome and other Chromium‑based browsers have shipped a new “customizable select” model that lets you fully style native selects with plain HTML and CSS, no ARIA‑heavy widget recreation required. Backed by a growing spec in the WHATWG HTML standard and fresh documentation on MDN, customizable <select> elements open the door to rich, accessible dropdowns that still behave like the controls users expect.
From experimental flag to stable Chrome feature
Customizable select began as an early prototype in Chrome Canary 130, hidden behind the #experimental-web-platform-features flag. At that stage it was squarely in the “try this on a demo page” category. The intent was to gather feedback on new CSS and HTML primitives that would unlock deep styling without breaking the well‑tested behavior of native selects.
Since then, the feature has matured into something you can realistically ship for many users. As of Chrome 135 and corresponding versions of Edge and Opera, customizable select is enabled by default when you explicitly opt in using CSS. The browser upgrades the element into a new, style‑friendly rendering mode while preserving forms integration and keyboard support.
The underlying proposal sits in WHATWG HTML Stage 2, which means it has a written explainer, initial spec text, and some cross‑browser interest, but it is not yet fully standardized. Chrome’s team has been clear that they want real‑world developer feedback: how does it fit into production design systems, does it play nicely with frameworks, and what gaps still force people back to JavaScript polyfills?
The core building blocks: appearance: base-select and ::picker(select)
At the heart of customizable select is a new rendering mode enabled by appearance: base-select. In the past, appearance has been a blunt tool: you could often only switch between “default” and “none,” with wildly different effects across browsers. In the new model, base-select is a well‑defined, standard appearance that unlocks specific CSS hooks for styling the control.
To opt in, you declare appearance: base-select; on both the <select> element and its corresponding picker pseudo‑element:
select, ::picker(select) { appearance: base-select; }
Once this is applied, the browser stops delegating the UI to the operating system and instead uses a UA‑defined layout that can be styled with regular CSS. The ::picker(select) pseudo‑element represents the dropdown listbox portion of the control. It only exists in this mode, if you never set appearance: base-select, the pseudo‑element is not created and you get the classic platform‑native select.
New CSS hooks: styling the button, listbox, icon, and checkmark
Previous attempts to style <select> often hit a wall because critical subparts, the arrow icon, the open state, the selected option marker, were not exposed to CSS. Customizable select changes that by introducing a set of dedicated pseudo‑elements and pseudo‑classes.
The ::picker(select) pseudo‑element is your entry point for styling the dropdown listbox itself. You can control its background, borders, typography, and layout, just like you would for a custom menu component. The browser still handles focus management and keyboard navigation; your CSS simply decorates the structure it provides.
The new ::picker-icon pseudo‑element targets the button’s icon or arrow, letting you replace the default triangle with any vector, character, or background image you like. Meanwhile, ::checkmark styles the visual mark shown on the currently selected <option>, which means you can design custom ticks, bullets, or even subtle highlight shapes. Two new pseudo‑classes round things out: :open matches the closed‑state button when its picker is open, and :checked matches the selected <option>. Together, these hooks give you the same visual control you’d have over a hand‑rolled dropdown, without having to reinvent its behavior.
Richer content in <option> and the new <selectedcontent> element
Classic HTML forms imposed a strict limitation on <option> elements: they were effectively plain text. That meant no inline icons, no multi‑line labels, and no structured content without resorting to non‑semantic wrapper elements or JavaScript clones. Customizable select relaxes this rule by allowing certain inline markup inside options.
Within the customizable select model, each <option> can contain richer inline HTML, such as icons, spans for secondary text, or layout wrappers. For compatibility with existing form behavior, browsers still treat the option’s submitted value as derived from textContent.trim. This preserves how forms serialize values, even when your options look more like mini list items than simple strings.
Chrome 135+ also introduces a new HTML element: <selectedcontent>. This element lives inside the first child <button> of a customizable <select> and mirrors the markup of the currently selected <option> in the control’s closed state. In practice, this means you can design a rich, icon‑enhanced label for each option and have the exact same markup appear in the button without any JavaScript wiring. As of early 2026 this is experimental and only implemented in Chrome 135+; Safari and Firefox do not yet support it.
Popover API integration and smart positioning
One of the subtle wins of customizable select is its tight integration with newer platform primitives, especially the Popover API and anchor positioning. When you opt into appearance: base-select, the browser automatically establishes a relationship between the select’s button and its picker that mirrors the invoker/popover model.
This means the dropdown acts like a popover: it can respond to :popover-open styling, follows focus in intuitive ways, and integrates with the platform’s notion of transient UI. You don’t have to manually manage ARIA attributes or keyboard shortcuts; the browser treats the control as a first‑class widget while still exposing its states to CSS.
On the layout side, the picker participates in anchor positioning. An implicit anchor is created so you can position the dropdown relative to the select using CSS anchors and position-try rules. The browser can then automatically flip or adjust the picker to avoid overflowing the viewport, similar to what advanced JavaScript dropdown libraries already do today, but built into the rendering engine rather than reimplemented per site.
Accessibility and behavior: native first, custom second
A recurring pain point with custom dropdowns has been accessibility. Rebuilding selects from scratch usually means re‑implementing keyboard navigation, focus management, and screen‑reader semantics with ARIA. That often goes wrong in edge cases or for users of assistive technology that developers never test with.
Customizable select takes a different approach by keeping the native control as the source of truth. Even in appearance: base-select mode, the element is still a real <select> that participates in form submission, respects system preferences, and exposes familiar semantics to screen readers. The new CSS hooks simply reveal internal parts that have always existed in some form.
As a result, you can design highly customized visuals without losing basic functionality like arrow‑key navigation, type‑a search, or focus outlines. Developers get the styling flexibility they’ve wanted, while users keep the reliability and predictability of native UI. This “native first, custom second” philosophy is a major shift from earlier eras of web UI where appearance and behavior were inseparable.
Browser support and practical rollout strategy
Despite the excitement, customizable select is not yet a universally available feature. According to Can I use data as of January 23, 2026, support sits around 70% global usage coverage. Implementation currently exists in Chromium‑based browsers: Chrome desktop 135+, Edge 135+, Opera desktop 120+, Chrome for Android / Android Browser 143+, and Samsung Internet 29+.
Firefox (desktop and Android) and Safari (on macOS and iOS, including Technology Preview) do not yet implement the feature. That means teams cannot rely on customizable select as the only solution for mission‑critical UI across all platforms. For now, it should be treated as a progressive enhancement layered on top of a robust, baseline experience.
In practice, that usually looks like starting with a standard <select> that is usable and accessible everywhere. Then, within a @supports block, you apply appearance: base-select and the new pseudo‑selectors to upgrade the control in supporting browsers. This approach ensures users on Firefox or Safari still see a functional native select, even if they miss out on the fancy styling.
MDN guidance, framework caveats, and known limitations
MDN has responded to developer interest by publishing a dedicated “Customizable select elements” guide, most recently updated on November 10, 2025. The documentation walks through building fully customized controls using only HTML and CSS, including styling the select button, dropdown picker, arrow icon, each <option>, and the selected option’s checkmark. It also includes detailed examples of using <selectedcontent> and inline markup inside options.
However, MDN is explicit about current risks and limitations. The guide labels the feature as experimental with limited browser support, and it flags potential compatibility issues with some JavaScript frameworks and server‑side rendering setups. Certain frameworks may treat additional child markup inside <select> as invalid, or interfere with the control’s internals during hydration, leading to mismatches between server and client renders.
Chrome’s own RFC‑style blog post also calls out that in appearance: base-select mode, there is no support yet for <select multiple> or <select size=n>. If your design heavily depends on multi‑select listboxes or non‑dropdown select configurations, you will need to keep using existing patterns for now. Checking both MDN’s compatibility tables and your framework’s documentation before a production rollout is strongly advised.
What this means for the future of form controls
Customizable select is more than a one‑off enhancement; it’s a signal of how the web platform might evolve to reconcile native controls with design‑system demands. By exposing structured, well‑defined styling hooks rather than forcing developers into full re‑implementations, browsers can offer both reliability and flexibility.
Articles like “Future of CSS: select styling without the hacks” have framed this feature as a turning point: for the first time, you can fully style native selects, button, listbox, icon, options, and checkmarks, purely with CSS, while retaining native keyboard and screen‑reader behavior. That could significantly reduce dependency on heavy dropdown libraries in many codebases.
Of course, the story isn’t finished. Cross‑browser implementations, expansion to multi‑selects, and resolution of framework/SSR issues will determine how widely customizable select is adopted. Developer feedback over the next few years will shape the spec’s evolution and may influence how other controls, like date pickers or file inputs, gain similar customization capabilities.
For now, customizable select in browsers gives developers a powerful new option: richer, brand‑consistent dropdowns that still behave like real form controls. By combining appearance: base-select, ::picker(select), and related pseudo‑elements with the new <selectedcontent> element, you can build experiences that once required complex JavaScript, while keeping the accessibility and semantics of native HTML.
If you choose to adopt it, treat customizable select as a progressive enhancement. Start with a solid baseline <select>, layer on customization behind feature detection, and test thoroughly in your framework and SSR environment. As standards mature and non‑Chromium browsers implement the feature, the gap between “native” and “custom” form controls may finally begin to close.