The Styling Problem at the Heart of the Web

Anyone who has wrestled with form design knows the pain: a native <select> dropdown or a checkbox can look wildly different from one browser to the next, and CSS often feels powerless to tame them. This long-standing frustration was the topic of a recent Smashing Podcast episode, where host Drew McLellan spoke with Microsoft engineers Stephanie Stimac and Melanie Richards about why HTML controls are so hard to style—and what the future might hold.

According to Stimac and Richards, the root of the problem isn't a lack of CSS features. It's structural. Native form controls are rendered by the browser's internal UI engine, which sits outside the regular HTML and CSS rendering pipeline. When a developer writes CSS that targets a <select> element, the browser has to interpret that CSS in the context of a widget that it internally considers a "replaced element"—an opaque box that doesn't expose its internals to the style engine the way a <div> does. That means things like custom animations, transforms, or pseudo-element tricks often fall flat or produce inconsistent results.

An Inconsistent Baseline

Stimac noted that the inconsistencies are most visible across operating systems. A form control built for Windows looks and behaves differently than one built for macOS, and those differences are coded directly into the browser engine. Developers are left trying to target subtle rendering quirks with vendor-prefixed or browser-specific hacks, yet the fundamental parts of the control's internal structure remain inaccessible. Richards added that some browsers allow styling of internal sub-parts through proprietary pseudo-elements like ::-webkit-search-cancel-button, but these are non-standard, unmaintained, and a liability for web developers who need predictable cross-browser behavior.

Because the user agent makes key decisions about the control's shadow structure, styling any part of it—even something as simple as a border or background on a dropdown's arrow—dedicates the element to a certain state of being "partly styled." That can trigger a fallback to a rendering mode that discards the CSS entirely, or in worse cases, locks an element to an unstyled default appearance. The upshot is that styling an HTML control often comes down to either ignoring the native parts or bulldozing over them with custom JavaScript-heavy components that recreate the behavior of the control from scratch.

Custom implementations are common—consider massive JavaScript libraries—but they bring their own baggage. Reimplementing interactions like keyboard navigation, screen reader announcements, and mobile-specific gesture handling is a brittle process. Stimac and Richards see this as strong motivation for their work on the Open UI project, an initiative to document and standardize the styling of native HTML controls, and to eventually bring native solutions to problems developers currently solve with hacks.

Path to Standardization

The central idea behind Open UI is to create a systematic way to style the internal parts of a control, and to define a consistent interface across browsers. Rather than proposing that developers get access to very specific ::-webkit-style pseudo-elements, the goal is a more generalized approach: an API that allows parts, states, and behaviors to be styled semantically. While that sounds ambitious, Stimac and Richards note that progress in this space is incremental and happens alongside the broader standards process—and that early framework work, like research into what parts people actually need to customize, comes first.

One technical approach explored in the project leans on the underlying facilities of the Shadow DOM. If a browser could define a control's internal structure via the Shadow DOM in an open (rather than closed) state, its inside parts would actually become styleable through CSS. In that world, a <select> is not a black-box widget; it is built from layers that a stylesheet can reach and reposition. This brings a range of controls (especially in their sub-parts, like the indicator arrow) closer to standard web behavior, with typical CSS properties working as they do on other element types.

Richards outlined the course from here: development of Open UI means gathering information about each common control—select, checkbox, date picker, and others—identifying the internal pieces and their states, and then baking this information into the standards recommendations. The hope is not just to standardize the styling ability, but to create a consistently authored internal tree that all development teams can rely on, in all browsers.

What Developers Can Do Today

While these standards are still gestating, the duo emphasized that improving developer experience doesn't always require waiting on the platform. Building custom controls with an "accessibility-first" mindset—ensuring they are keyboard navigable, operable by screen readers, and responsive to touch—is a pragmatic recipe for shipping pleasant forms today. And even when battling with native parts, documenting hacks, and moving feature-by-feature toward a better baseline are a practical contribution.

Stimac and Richards agree that the future of HTML controls is bright, although the path is slow. Conversations like these, plus actual work in browser engines and standards groups, move the web toward a reality where a custom-styled <select> won't need a JavaScript workaround underneath it.

Show notes from the episode:

The Control Problem

When Melanie Richards and Stephanie Stimac talk about HTML controls, they mean the native form elements that handle user input: select, radio buttons, checkboxes, buttons, and even video player controls. For most developers, these elements present a familiar frustration. Something as simple as matching a select dropdown's option colors to a brand requires recreating the whole control from scratch, which brings its own set of problems.

Richards describes the irony: a developer wants custom icons in select options, so they rebuild the control, and suddenly they're managing semantic accessibility, keyboard interactions, high-contrast modes, and color schemes. "You recreate the select and now you have 37 problems," she says, quoting a tweet from the developer community. This work gets duplicated across teams, frameworks, and companies, when the ideal outcome would be to extend what ships in the browser rather than replace it.

The root cause goes back decades. In the early web, the operating system rendered controls natively, giving them a consistent platform look and feel. As CSS matured and developers wanted more styling power, controls diverged in behavior across sites and platforms. The result is a fragmented user experience where the same select element might handle keyboard input differently from one website to another.

Part of the difficulty in fixing controls is web compatibility. Any change to how a control behaves or renders risks breaking millions of existing sites. Developers have been applying CSS that has no effect on some controls for years; if browsers suddenly allowed those properties, sites would start rendering in funky ways. Add to this that browsers have implemented controls differently under the hood—some leaning on the operating system, some building their own—and you have a problem space that requires an additive, careful solution.

The Open UI Effort

Open UI is an initiative under the W3C (the "YCG" as Stimac refers to it) focused on standardizing the internal structure of controls. The original HTML 2.0 specification standardized what controls did, but not what they were made of. That left browser engines free to build them however they chose underneath, which in turn made it impossible to expose the individual parts to developers in a compatible way.

Stimac, who sits in on Open UI meetings, says the level of granularity is astonishing. "There are some meetings we have that get into such granular detail about the way a select behaves, just to a level that even kind of blows my mind," she says. The goal is to define what a select is comprised of, piece by piece, so those parts can eventually be standardized and exposed for styling and replacement.

The proposal defines several approaches for customizable controls:

  • Named parts with pseudo-elements: Giving controls a standardized internal structure so CSS pseudo-elements can target specific pieces. Greg Whitworth at Salesforce, who leads Open UI, has a proposal for a pseudo-element targeting checkbox and radio indicators.
  • Named slots: Letting developers replace one piece of a control—say, the button portion of a select—without recreating the whole element.
  • Full shadow DOM replacement: Allowing developers to replace the entire shadow DOM of a control using an attached method, while still relying on the platform's built-in controller logic to connect the model (data) and the view.

This effort doesn't extend to how controls look. "When you have different companies like Microsoft or the different browsers, they are different companies with different design languages as well," Stimac explains. The default styles will inevitably reflect each browser's own design system, which both guests agree is healthy for innovation. It also serves as a useful stress test: if the spec is flexible enough for browser vendors to build their own distinct controls, it's likely flexible enough to serve developers' styling needs.

Why Custom Isn't Always Better

If controls are such a pain, why not abandon them entirely and build with plain editable elements? Richards pushes back hard on that idea. Semantic HTML matters enormously for accessibility. Assistive technologies rely on the structure and built-in behaviors of native elements to know what users are interacting with and how to input actions and data.

"People can just say, well JavaScript is in their browsers or content can be kind of ingested into other environments," Richards says. The answer is to work declaratively, provide progressively enhanced experiences, and not depend on JavaScript for everything.

The risk of going rogue is visible in the hidden accessibility tax. When every site implements its own keyboard pattern for lists or autocompletes, users of assistive tech face "heavy cognitive overload" trying to relearn controls from site to site. Something that feels like a minor styling decision can multiply into an interaction inconsistency for a huge segment of users.

A survey run by Greg Whitworth confirmed the scale of the problem across the developer community. Around a third of the roughly 1,400 respondents rebuilt controls because they couldn't style them enough, and another third cited browser inconsistencies. Stimac later ran her own informal Twitter poll about the pain of styling selects; answers included preferring to "chew on glass or boil my toes in lava" rather than attempt to style a native select element.

A New Pop-Up Element

An explainer published ahead of this discussion introduces a proposed popup element, intended as top-layer UI with "light dismiss" behavior: closing on Escape or loss of focus. Only one pop-up is available at a time, unless pop-ups exist in an ancestry chain.

Richards sees this as a building block for customizable selects—the list box portion of the control is effectively a pop-up. But the broader use case is the many custom component libraries that resort to "stuffing divvy pop-ups in the bottom of the body" to escape rendering constraints. The proposal addresses a classification of UI that is widely rebuilt and challenging to get right, including focus trapping, scroll behavior, and z-index layering.

"It's 20 minutes here, 30 minutes there, but multiply that by every single developer who has to do that," Richards says about implementing pop-up behavior. Even a early-stage abstract spec and prototype attempt offer improvements over reconstructing a functional pop-up from scratch per project.

Richards stresses that the proposed element is a base to build on. Some classes of top-layer UI, like menus, may warrant their own element because their interaction patterns are distinct. The goal is finding a middle ground between pushing the platform forward and flooding it with new elements that may not prove evergreen.

What's In the Works

On the Chromium side, the controls got a visual refresh, an effort that started as Microsoft Edge discussed moving to the Chromium rendering engine. Edge's team wanted controls to suit touch screens (common on Windows laptops) and align with Microsoft's Fluent design. Google, meanwhile, was looking to update its own controls. The two teams and other Chromium vendors collaborated to land on a refreshed design that works across browsers and aesthetics, with the work still ongoing for Android.

Stimac mentions that Chrome is prototyping a native toggle switch element to address the common pattern of turning options on or off, which is useful because the work of upgrading a checkbox into a toggle is otherwise awkward.

The process for turning these ideas into web standards is slow by intent. "You actually probably should want us to take a while," Richards says, adding that it means the platform is making deliberate choices. Open UI functions as a maturation ground where proposals are worked on via pull requests and discussions before becoming mature enough to be proposed against the living HTML spec. She estimates it will take a couple of years at least to go through all the controls.

For developers who want to contribute, the options are open. Getting involved in Open UI at open-ui.org offers a way to define control structures or help with research. Feedback can also be given as issues on the explainers, hosted in Microsoft's Edge explainers repo on GitHub. Or, as Stimac puts it, as simple as sending a tweet to her or Richards.