The <select> element can now be customized with CSS

Original Article ↗ Hacker News Discussion ↗

Overall reaction and significance

  • Many see customizable <select> as “20 years late” but hugely positive, potentially replacing heavy JS custom select libraries.
  • Long‑time web developers express disproportionate excitement because native selects have long been a stubborn styling outlier.
  • Some hope this will spur more native UI primitives (combobox, typeahead, tag selectors) so apps can drop dependencies.

Browser support, standards, and rollout concerns

  • Current support is Chromium‑only; caniuse shows ~46% global support.
  • Strong emphasis on using this as progressive enhancement: the basic <select> must remain fully usable where unsupported.
  • People expect several years before it’s safe for broad public sites, with Safari again seen as the bottleneck; Firefox has signaled interest.
  • Some worry that constant API growth makes life harder for non‑Chromium engines and accelerates de‑facto Chrome dominance.

Feature gaps and behavioral trade‑offs

  • multiple and size attributes are not yet supported; in tests, multi‑select falls back to the old UI, seen as a “huge miss” that should at least be clearly documented.
  • Using appearance: base-select removes key native behaviors:
    • No rendering outside the browser window.
    • No invocation of OS‑native pickers on mobile.
  • Loss of native behavior raises concerns about mobile UX, reliability, and phishing/“fake dialog” risks if more power were granted.

Accessibility, UX, and progressive enhancement

  • Reminders not to rely on styling alone for critical info (color/shape, custom decorations), both for non‑supporting browsers and assistive tech.
  • Some argue many controls are worse when heavily restyled (parallels with scrollbars), but others want richer option content (icons, structured rows, swatches).
  • Internal apps may choose to ignore older browsers; public sites should not.

Native widgets vs JS “div monsters”

  • Widely welcomed as a way to avoid fragile, inaccessible JS dropdowns and “div‑based controls” that reinvent form behavior.
  • Discussion branches into other half‑baked or missing HTML widgets (dialog, date/time, combobox, datalist autocompletion) and the slow, fragmented standards process.