How the early 2026 customizable HTML <select> API replaces JavaScript dropdowns

Tuesday 26 May 2026, 02:04 PM

How the early 2026 customizable HTML API uses appearance: base-select and native anchor positioning to replace JS dropdowns with accessible, CSS-driven UIs.

For over two decades, if you wanted a dropdown that didn’t look like it belonged in Windows 95, you had to pay the JavaScript tax. We’ve all done it. We pull in libraries like React Select, swallow the 20KB to 30KB of bundle bloat, and spend hours manually mapping ARIA attributes just to get a branded UI.

Now, in early 2026, the web platform is finally trying to bail us out. Google just shipped full stable support for the Customizable Select API in Chrome 135. Apple has documented support in Safari Technology Preview 238, and Mozilla is actively prototyping it behind a flag in Firefox Nightly.

The frontend community is already calling this the death of the JavaScript dropdown. But before we start ripping out our custom form controls and popping champagne, we need to take a hard look at what this API actually does, what it breaks, and whether we really need the sheer amount of complexity it introduces.

Unpacking the mechanics of appearance: base-select

The core of this update hinges on a single CSS property: appearance: base-select. By opting in, you strip away the restrictive User Agent stylesheets that have locked down the <select> element since the dawn of the web.

Once you opt in, you get access to a new architectural handle called <selectedcontent>. Originally proposed as <selectedoption>, the W3C and Open UI working groups thankfully renamed it after folks like Jake Archibald pointed out the obvious developer confusion it would cause with the standard <option> tag. Its entire job is to mirror the inner HTML of whatever option is currently selected.

The most genuinely useful part of this update is how it handles the dropdown panel itself via the new ::picker(select) pseudo-element. By leveraging native CSS Anchor Positioning, the dropdown can finally escape overflow: hidden constraints and intelligently position itself in the top layer. We no longer need third-party JS calculation libraries like Floating UI just to keep a dropdown from clipping behind a container boundary.

From a performance standpoint, eliminating that JavaScript overhead is a clear win for Core Web Vitals. But the way this API achieves its visual flexibility raises some immediate red flags.

The hidden cost of a relaxed parser

To allow for custom styling, browser vendors had to implement "SelectParserRelaxation." Historically, the HTML parser was incredibly strict about what could live inside a <select> element. If you put an image or a <div> inside an <option>, the browser stripped it out.

Now, the parser is relaxed. You can throw rich HTML, images, SVGs, and complex flex or grid layouts directly inside your <option> tags.

My immediate question is: who is asking for this?

While standardizing design systems is a noble goal, giving developers the ability to shove massive, complex DOM trees into a simple form control feels like a recipe for layout thrashing and over-engineered UIs. Just because you can put a multi-column grid with inline SVGs inside a dropdown doesn't mean you should.

Furthermore, this relaxed parser introduces a very real risk of legacy breakage. If you have an older codebase with sloppy HTML—where invalid tags were accidentally nested inside a <select> and quietly ignored by the browser for years—that invalid markup is suddenly going to render. We are trading JS bundle bloat for potential DOM bloat and unexpected visual regressions on older sites.

Fixing the multi-select UX

Where I will give this update unreserved praise is in its modernization of <select multiple>.

For years, selecting multiple items in a native HTML list box required users to hold down modifier keys like Ctrl or Cmd while clicking. It was an archaic, hostile user experience that completely failed on touch devices and confused non-technical users.

The early 2026 update finally removes this legacy requirement for mouse users, aligning native multi-select behavior with modern UI patterns. You just click to toggle. It retains the native C++ accessibility mappings under the hood, meaning screen readers still understand exactly what is happening without us having to write a single aria-selected="true" attribute. This is the kind of practical, user-centric improvement the web platform desperately needs.

The reality of progressive enhancement

The Customizable Select API is a massive technical achievement. Getting Chrome, Safari, and Firefox to align on something this foundational is no small feat in the Silicon Valley ecosystem.

But let’s be realistic about adoption. Because this relies on new HTML elements and CSS properties, you can't just drop it into an enterprise application today without a fallback. We are going to be living in a world of progressive enhancement for years, meaning we have to support both the new native API and our legacy JavaScript dropdowns for users on older browser versions.

We aren't eliminating the JavaScript tax just yet; for the foreseeable future, we are just adding a CSS tax on top of it. The Customizable Select API is a powerful tool, but it requires restraint. Before you rewrite your entire component library, ask yourself if your users actually need a rich-media experience in their form inputs, or if they just want to pick an option and move on.

References

Read more posts about User experience (UX)

Subscribe to our mailing list

We'll send you an email whenever there's a new post

Copyright © 2026 Tech Vogue