Customizable Select: Keep Options Readable in Older Browsers
A product-color dropdown shows neat swatches in Safari 27 and Chrome. What do shoppers on an older browser see when the styling falls away?

- Keep readable text in every option so a classic select still makes sense.
- Apply appearance: base-select to both the select and its picker to style the whole control.
- Safari 27 and Chrome 135 support this model; its mobile picker is different from the operating system's default UI.
An option needs a name after the decoration disappears
Keep actual text inside each option. That is the key to a styled select that remains usable when a browser falls back to its classic control. A color swatch alone may disappear in that fallback, leaving an empty choice. WebKit's guidance treats icons and swatches as additions to meaningful text.
With customizable select support in Safari 27, more developers can style a native dropdown instead of replacing it with a JavaScript widget. It does not remove the need to tell users what each choice means.
Start with a working form, then add the styling
This illustrative size selector keeps a readable name and an explicit value for every choice. The associated label identifies the input.
<label for="size">Size</label>
<select id="size" name="size" class="size">
<button><selectedcontent></selectedcontent></button>
<option value="s">Small</option>
<option value="m">Medium</option>
<option value="l">Large</option>
</select> The optional selectedcontent element displays a clone of the selected option inside the button. That browser behavior removes the need for a separate script just to update the button's label. MDN documents the markup and rendering model.
@supports (appearance: base-select) {
select.size,
select.size::picker(select) {
appearance: base-select;
border: 1px solid #64748b;
border-radius: 0.5rem;
padding: 0.5rem;
}
} The two selectors target different parts: the closed select and the dropdown picker. Opt both into base-select to customize both. The feature query confines these enhancements to supporting browsers.
For a color selector, extend this pattern with a decorative swatch beside the color's written name. The swatch helps recognition; keeping “Blue” or “Red” supplies the information when that decoration is absent.
The displayed name does not have to be the submitted code
In this example, “Medium” submits the value m. According to the option reference, an explicit value supplies the form value; without it, the option's text is used.
For a form connected to an existing API, assigning stable values is a useful implementation choice. You can revise the display names without also revising those codes. Cloning the selected content into the button does not define your server's data contract.
Expect a useful fallback, not identical rendering
Safari 27 shipped customizable selects, and Chrome introduced support in 135. Browsers without support should still present the size names through their classic select. Matching every visual detail is a separate requirement from preserving the form's meaning.
Mobile deserves its own check. The base-select rendering mode does not invoke the operating system's built-in mobile picker. Test touch targets and long labels on the screens your form serves.
Finish the text and values first, then decorate them. That gives the enhanced control and its fallback the same choices without maintaining a second simulated select.