Intro

Chrome 135 introduces a customizable version of the HTML <select> element that gives designers real CSS control over dropdowns while keeping them accessible and standards-based. Instead of relying on complex JavaScript widgets, teams can now style native selects directly in the browser, aligning form controls with the rest of their design systems and reducing maintenance overhead for templates and production sites.

{getToc} $title={Table of Contents}

Intro

According to Chrome for Developers, the new behavior arrives in Chrome 135 and is powered by the appearance: base-select CSS value, which puts <select> into a standardized, styleable state. This approach exposes new internal parts, moves the options list into the top layer like a popover and keeps JavaScript interfaces unchanged, so existing code that reads or sets select values continues to work as before.

The official article The <select> element can now be customized with CSS shows how developers can add rich HTML inside options, bring their own button and arrow markup and use the ::picker(select) pseudo-element to control the dropdown panel. Older browsers fall back to a classic select UI, which makes this a progressive enhancement rather than a breaking change.

{getCard} $type={post} $title={READ ALSO} $info={More Chrome and web platform changes for front-end developers} $icon={}

Demo of customizable select elements in Chrome 135 (video, if available).

With customizable select, Chrome 135 lets developers opt in using appearance: base-select and then style both the button and the dropdown panel, including rich HTML content inside <option> elements. The options list is rendered in the top layer and positioned with anchor(), while browsers that do not support the feature simply display a traditional select, keeping forms functional across older environments.

REMEMBER: Treat customizable select as progressive enhancement and always ensure that your forms remain usable with the default HTML <select> in unsupported browsers. {alertSuccess}

Availability and requirements

The customizable select experience is available starting in Chrome 135 on desktop and Android, rolling out through the normal stable-channel update process. Sites already using native <select> elements do not need any markup changes to keep working; developers only need to add the new CSS opt-in and styles where they want enhanced dropdowns.

Because this feature is built on top of standard HTML and CSS, it does not require extra JavaScript libraries or new APIs. Teams should still test their forms in multiple browsers and viewport sizes to confirm that the base-select layout, top-layer dropdown and fallbacks behave correctly in their specific design systems.

Impact

For template authors, theme creators and UI kit maintainers, customizable select is a significant quality-of-life improvement. It closes the long-standing gap between visually polished, JavaScript-heavy dropdown components and simple but rigid native selects, allowing both accessibility and brand-consistent styling to coexist in one control.

As support grows beyond Chrome, this approach should reduce the need for custom select widgets in design systems and front-end frameworks. That means fewer compatibility issues, simpler codebases and a more consistent experience when users interact with form elements across sites built with modern HTML and CSS.

{getCard} $type={custom} $title={Wait} $info={There are more news stories to read...} $icon={}

More information and sources

• Original coverage by the editorial team