Customizable Select

A native <select> dropdown fully restyled with CSS — no div-based fake-dropdown, no JS listbox library, no ARIA hand-rolled from scratch — via the new appearance: base-select value plus the <selectedcontent> element and ::picker(select)/::checkmark pseudo-elements. You opt in with appearance: base-select on the select and on ::picker(select); a <button><selectedcontent></selectedcontent></button> as the select's first child becomes the styleable trigger (the browser clones the selected <option>'s content into it), and the popup itself becomes stylable via ::picker(select). Real, current, sourced support as of this run: the Chrome for Developers blog post 'The <select> element can now be customized with CSS' (developer.chrome.com/blog/a-customizable-select) and MDN's Learn guide both confirm the property/value pair plus <selectedcontent> shipped stable in Chrome/Edge 135; cross-checked against a second, independent query specifically targeting the version number, which agreed (introduced behind experimentation in Chrome 134, stable from Chrome 135). Safari and Firefox are NOT asserted as shipped: every source found this run places Safari behind Technology Preview only (not a stable release) and Firefox behind a flag in Nightly — left unconfirmed in stable rather than rounded up, same policy as prior entries when WebFetch to caniuse.com/webkit.org (blocked by this environment's egress policy) can't settle it directly. Degrades with zero functional loss: MDN's guide states the <button>/<selectedcontent> markup is ignored entirely in a non-supporting browser, and non-text <option> content (icons, extra markup) is stripped down to its plain text — the result is an ordinary, fully working native <select>, not a broken or empty control. **Verification caveat, stated honestly rather than assumed:** the static trigger renders and clones the selected option's text correctly (confirmed by real Playwright screenshot, this run), but the interactive click-to-open custom popup could NOT be confirmed working in this environment — real Playwright testing against this sandbox's actual Chromium 141 (tested headless, headed via Xvfb, and with --enable-features=CustomizableSelect/StylableSelect and --enable-blink-features=CustomizableSelect all explicitly set) consistently shows the outer <select> intercepting the click meant for the inner trigger button and the select's :open state never becoming true, even though CSS.supports('appearance','base-select') and getComputedStyle both report the property as engaged. This looks like a gap between this environment's open Chromium testing snapshot and a real Google-Chrome-branded stable build (many newly shipped Chrome features are gated by a server-side Finch config that generic Chromium builds don't receive), but that theory is unconfirmed — flagged as an open item for verification on a real Chrome/Edge 135+ browser outside this sandbox, not asserted as working. (Vanilla example: live iframe preview + HTML/CSS tabs — the styled trigger renders correctly; whether the popup opens on click depends on your actual browser, unconfirmed from this environment.)

<div class="cs-wrap">
  <label class="cs-label" for="cs-demo">Framework</label>
  <select class="cs-select" id="cs-demo">
    <button class="cs-trigger" type="button">
      <selectedcontent></selectedcontent>
      <span class="cs-arrow" aria-hidden="true">&#9662;</span>
    </button>
    <option class="cs-option" value="react">React</option>
    <option class="cs-option" value="vue">Vue</option>
    <option class="cs-option" value="svelte">Svelte</option>
    <option class="cs-option" value="astro" selected>Astro</option>
  </select>
  <span class="cs-note">Needs Chrome/Edge 135+ for the custom popup — a normal working native select everywhere else</span>
</div>