Customizable HTML Select

Original Article ↗ Hacker News Discussion ↗

Longstanding pain with <select> and custom dropdowns

  • Many commenters have repeatedly rebuilt custom selects over the years, often with large amounts of JS and complex event/ARIA handling.
  • Third‑party libraries exist but are seen as heavy, imperfect, and often inaccessible; multiple people dispute that this is a “solved problem.”
  • Several welcome a standardized, rich <select> that might reduce the need for bespoke JS components and bad React‑land comboboxes.
  • Others doubt it will meaningfully reduce custom solutions driven by design demands.

Standardization, Chrome implementation, and browser politics

  • The feature is described as a redesigned “customizable select” reusing <select>, not the earlier selectlist proposal.
  • It’s in WHATWG Stage 2 with apparent cross‑browser interest; links to WHATWG and Open UI issues/specs are shared.
  • Some accuse Chrome of pushing Chrome‑only CSS and repeating the IE era; others counter that this is an experimental implementation of a standards‑track feature behind a flag.
  • Skeptics argue Firefox will lag, creating a long Chrome‑only window; defenders point out vendors are criticized both for moving too slowly and too fast.
  • Apple/WebKit is criticized for blocking customizable built‑ins in the past; others say newer proposals avoid old downsides.

Accessibility and UX implications

  • Strong agreement that native selects are usually more accessible than JS re‑implementations; making them stylable is framed as an accessibility win.
  • Customizable select is tied to related work on comboboxes and multi‑select support in Open UI.
  • Multiple select’s UX is debated: some say it’s fine if you know desktop conventions; others note confusion around modifier‑key behavior and its poor fit for touch devices.
  • There’s interest in filterable/select‑with‑search; respondents say that belongs more to a future combobox than basic select.

Missing native components and HTML vs JS debate

  • Several lament that, after decades, the platform is only now fixing <select> while lacking native datagrid, tabs, toggle, virtual lists, image cropping, etc.
  • Others argue:
    • HTML is a semantic toolkit, not a full UI framework.
    • Complex widgets like datagrids are hard to standardize across vendors and must serve many use cases.
    • Social/organizational friction and backward compatibility slow specs, not just technical difficulty.

Web components, CSS, and broader frustrations

  • Web components are criticized as overcomplicated, especially around shadow DOM, styling (::part, ::slotted limits), and global registration; some still find them useful in “HTML web components” style without heavy shadow usage.
  • Concerns are raised about CSS syntax complexity and changing specs (e.g., anchor positioning).
  • The autocomplete ecosystem is widely viewed as broken in practice, with browsers’ heuristics often ignoring autocomplete=off and developer intent, though some argue this is a reaction to sites misusing it.