A select should tell you something

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, you need to know what Fraunces looks like. After, you see it.

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, you work out the time from the offset. After, the list tells you, and whether it’s day or night.

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.

Same-day courier
Delivered today by 9 pm if you order before 2 pm. Costs $14.00. Express
Arrives tomorrow. $8.50, tracked. Standard
Our usual service: 3 to 5 business days for $3.90. Pickup point
Free. Collect from a pickup point near you in 2–3 days.

Before, the details hide in sentences and take the whole panel. After, the same choice fits in one field, with arrival and price lined up.

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.

Two people share a name. Before, you guess. After, the title and department make them two different answers, even once the list is closed.

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, you find out a team needs approval after you’ve shared. After, you know while you’re choosing.

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.

---

Originally published at alfy.blog.