Chrome CSS | Customizable select gives designers native UI control

Chrome has introduced new CSS customization support for the native <select> element, giving web designers more control over dropdown interfaces without abandoning standard browser behavior. Published on March 24, 2025, the Chrome for Developers article explains how Chrome 135 adds appearance: base-select, rich option content, customizable internals, and a more flexible styling model for native form controls.


Chrome CSS customizable select element for native web interface design

{getToc} $title={Table of Contents}

Chrome makes the native select element easier to design with CSS


The native <select> element has always been useful, but difficult to style. Many designers and front-end developers have replaced it with custom JavaScript components because the default browser control often does not match modern UI systems, brand styles, or polished template designs.


This update is exciting for web design because it brings more visual control back to the native element. Instead of rebuilding dropdowns from scratch, designers can work with a standardized control that supports richer styling while keeping important accessibility and platform behavior closer to the browser.



How appearance: base-select changes dropdown styling


The main feature is appearance: base-select, a CSS value that places the <select> element into a new configurable state. Chrome explains that this unlocks new internal parts, states, top-layer option behavior, anchor-based positioning, and a minimal visual base optimized for customization.


With this approach, a select menu can include richer HTML content inside options, such as icons, labels, or structured visual elements. That is a big shift from the older behavior, where browsers would ignore many custom elements inside <option> and limit how much designers could control the final interface.


New options for form UI and template design


For template creators, this makes form design more flexible. Dropdowns can now better match dashboards, settings panels, profile forms, filter menus, pricing selectors, language pickers, publishing states, and theme configuration screens without immediately requiring a custom JavaScript replacement.


The update also matters for maintainability. Native controls are usually easier to connect with forms, validation, keyboard navigation, and existing JavaScript logic. Chrome notes that the JavaScript interfaces for <select> remain unchanged, which helps preserve compatibility with existing projects.


For web designers, the practical benefit is a cleaner balance between design freedom and platform reliability. A styled native select can feel more integrated into a modern UI kit while still using the browser's built-in form behavior.


Availability and implementation notes


Chrome says customizable select support starts in Chrome 135. The article also notes that Chrome is the first browser to implement base-select, while the broader specification work includes participation from other browser vendors.


For production websites, designers should test support carefully before replacing existing dropdown systems. A good adoption path is to treat customizable select as progressive enhancement: keep the form usable everywhere, then add richer styling where the browser supports the new CSS behavior.


Daisuki's Take: What This Means for Web Designers


We see customizable <select> support as a practical improvement because it brings more design control back to native form elements. The real value is not only making dropdowns look better, but reducing the need to replace standard browser controls with heavier custom JavaScript components.


For web designers and creative teams, this can help when building forms, dashboards, filters, settings panels, language selectors, pricing tools, and template interfaces. A styled native select can match a visual system more closely while still preserving familiar form behavior and a cleaner implementation path.


The limitation is that browser support and implementation details still need careful review. We still need to test fallbacks, keyboard behavior, accessibility, responsive layout, and whether richer option content improves the experience instead of making the control harder to understand or maintain.



Sources and Recommended Links