Heads up: your browser doesn’t support customizable selects yet, so the “after” demos below look like ordinary selects. That’s also exactly what your visitors would see in this browser. To see the difference, open this page in Chrome or Edge.
There are multiple articles about appearance: base-select and how you can use it. We finally can style a select. The bigger change is what an option can hold. Until now, an option was one line of plain text, so everything a person needed to decide had to fit in a label or be left out. Now an option can carry the thing people actually decide with: a preview, a number, a job title, a warning. They stop reading and working things out, and start recognising.
Below are five selects, each shown before and after. The before is what most forms do today. The after is the same <select>, with the same keyboard behaviour and the same form value. Only what it shows has changed. If you want the mechanics, the Chrome team’s announcement and MDN’s guide cover them well.
See it, don’t imagine it
A font picker usually lists names. To choose well, you either already know what Fraunces looks like, or you pick it, look at the result, and come back to try the next one.
When each option is set in its own typeface, the option is the preview. You judge the shape, not the name.
Before
After
This pattern is not new. We already have in document editors (like Google Docs) and in design tools (like Figma and Photoshop). It just became available for us and all we need is one inline style per option, style="font-family: 'Fraunces', serif", and the closed control keeps the typeface after you choose. We are also able to show the category of each font, like Serif, Sans, Mono, Display, or Handwriting.
Let the list do the maths
Time zone pickers tend to look like “(GMT+09:00) Tokyo”. The offset is accurate and almost never what you want. What you want is the time there, so you add the offset to your own time in your head, and maybe get it wrong around midnight.
Show the current time next to each city, plus whether it’s day or night, and the question answers itself before you choose.
Before
After
This is the only demo that needs JavaScript, because the times come from Intl.DateTimeFormat.
Compare at a glance
Delivery options are usually a group of radio buttons, each with its details written out as a sentence.
To be fair, radio buttons have a real strength. Every option is visible without a click, and for two or three short choices they’re the right pattern. But once each option carries a few facts, the facts end up in prose. Comparing means reading every sentence and holding the numbers in your head.
A select with the facts in aligned columns turns that into a glance down a column, in the space of a single field.
Before
After
The columns are a grid on each option:
option { display: grid; grid-template-columns: 1fr 6.5rem 4rem; }
Tell people apart
At a company of about two hundred people, we had two colleagues with the same name, in different departments. Whenever I had to pick one of them, I went by their job title. Photos help less than you’d think, because people often don’t know what a colleague looks like, especially one in another department.
A text-only select gives you two identical options and a guess. Put the title and department under each name and they become two different answers. The closed control keeps the title too, so anyone reviewing the form can see who you picked.
Before
After
Know before you choose
Some options come with consequences. In a plain select, you find out afterwards.
Mark those options in the list and you know while you’re choosing.
Before
After
The badge appears only on the options that require special attention, and nowhere else.
It’s still a select
Every “after” in this post is a plain <select>. Keyboard handling, type-to-jump, form submission, select.value, required, validation and the accessible role all stay with the browser, and the control itself needs no JavaScript.
The bigger trade-off is on phones. A native select opens the operating system’s own picker. It shows a scrolling wheel on iOS, a sheet on Android. Those are familiar, sized for thumbs, and tuned to each platform’s accessibility features. A customizable select doesn’t use them; it draws its own list on the page instead.
You don’t have to pick one behaviour for everyone. Opt in only where there’s a mouse or trackpad, and touch devices keep their native picker:
@media (hover: hover) and (pointer: fine) {
select,
::picker(select) { appearance: base-select; }
}
/* Or we can rely on the window size */
@media (min-width: 768px) {
select,
::picker(select) { appearance: base-select; }
}
Phone users then see each option’s text without the extras, which is one more reason the text has to stand on its own. The demos in this post opt in everywhere, so you can try them on any device.
Start using it today
Customizable select is a textbook progressive enhancement. A browser that doesn’t support it doesn’t break. It shows a regular native select, keeps only the text of each option, and submits the same value. Nobody gets a worse form than they have today. If you’re reading this in Firefox at the time of writing, the “after” demos above are exactly what your visitors would see.
That leaves one requirement, and it’s good practice anyway. The text of every option has to make sense on its own. “Ahmed Mostafa, Accountant · Finance”, not just a name. “Express, Tomorrow, $8.50”, not three loose fragments. In the demos, small separator spans that are hidden in the customized version make the plain version read like a sentence. No polyfill needed.
So there’s no reason to wait. Find the select in your product where people hesitate the most, ask what they’re really trying to find out, and put that answer inside the option. Leave everything else out.