UI Elements - Basics, Best Practice, and Built Ins

Episode Summary

Executive Summary: The episode surveys common web UI elements—what works well in browsers, what remains clunky, and what Open UI is doing to standardize better primitives. Wes and Scott highlight strong built-ins like dialog, progress, range, and button, while critiquing weak ones like date pickers, media controls, and native alerts. They also explore accessibility, CSS :has(), and emerging proposals such as select menu, popover, and focus group.

Main Topics: Native UI elements that fall short: The hosts critique browser-provided controls that are hard to style, inflexible, or overly rigid, especially date pickers, video/audio controls, and alert/prompt/confirm dialogs. Built-in elements that work well: They praise elements like dialog, progress, range inputs, and buttons for offering useful APIs, decent defaults, and easier styling or accessibility support. Open UI as a standards research hub: Open UI is presented as a major initiative researching patterns and proposing standardized controls to improve web platform primitives and inform future browser APIs. Specific UI proposals and research: They discuss proposed or researched components such as checkbox, exclusive accordion, file, popover, select menu, breadcrumb, and focus group, with emphasis on behavior and accessibility. Accessibility and CSS/HTML evolution: The conversation emphasizes accessible-by-default controls, including declarative triggers, roving focus, and how :has() can reduce JavaScript while improving state-based styling. Component naming and framework conventions: They briefly examine Open UI’s component matrix, noting which UI concepts are broadly standardized in frameworks (button, tooltip, tabs, breadcrumb) and which are niche.

Key Arguments: Browser-native controls are often too rigid or ugly to replace custom implementations, so developers still reach for libraries and custom markup. Some built-ins are genuinely useful because they save time and bring accessibility and predictable behavior, especially dialog, progress, range, and button. The web needs better primitives that combine native behavior with stronger styling hooks and more flexible APIs. Open UI is important because it gathers research and consensus before proposals move to standards bodies like CSSWG, WHATWG, W3C, or TC39. Accessible-by-default UI patterns should be handled by the browser whenever possible, because developers frequently miss or skip accessibility work when they must build everything themselves. The :has() selector and future declarative UI features can simplify state-driven interfaces and reduce custom JavaScript. Some patterns, like exclusive accordions or focus groups, are distinct enough to deserve their own standardized treatment rather than being treated as generic markup.

Data Points: UI framework naming for button: 89% - Open UI component-name matrix; button is one of the most consistently named components across frameworks. UI framework naming for menu: 74% - Open UI component-name matrix; menu is another widely standardized component name. UI framework naming for accordion: 42% - Open UI component-name matrix; accordion is common but less universal than button/menu. UI framework naming for breadcrumb: 5th most common - In the hosts’ top-five recall of Open UI’s matrix, breadcrumb was among the most common component names. Checkbox state proposal: indeterminate - The checkbox proposal includes an additional state where the control is neither clearly on nor off when loaded. Popover/trigger accessibility: automatic configuration - Open UI describes declarative triggers that automatically configure accessibility mappings for associated popovers. Popcorn batch capacity: 500 batches - Scott says a box of Flavacol lasts for about 500 batches of popcorn. Flavoring product price: $9 - Scott notes the popcorn seasoning purchase was around nine dollars.

Pivotal Quotes: "Wouldn't it be nice to have a bit more primitives that didn't suck in the browser?" — Scott Delinski: Early framing of the episode’s core theme: improving web-native UI controls. "The browser will determine how the UI handles with this." — Scott Delinski: Explaining how current date input behavior is left to browser implementation, leading to inconsistent and weak UX. "Wouldn't it be nice if the standards were accessible by default and you didn't have to do a whole bunch of extra work to just to make it accessible?" — Wes Bos: Discussing the value of Open UI and browser-native components that handle accessibility for developers.

Implications: Listeners should expect more browser-native controls over time, but the short-term reality is still a mix of native elements, custom components, and standards work. Open UI and features like :has() point toward more accessible, configurable UI primitives in the future.