我每次看到設計稿裡那個「很簡單的下拉選單」都會先嘆一口氣。設計師看到的是圓角、陰影和一個漂亮箭頭，前端腦中跑過的卻是鍵盤操作、focus、螢幕閱讀器，還有手機上到底會跳出什麼。這個問題大家重做了那麼多年，原生 select 終於願意多讓我們改一點，老實說我有點驚訝。
原生 <select> 好用、支援鍵盤，也有不錯的無障礙基礎，但一直很難配合網站設計。很多團隊只好用 div 和 JavaScript 自己重做下拉選單，結果又得重新處理鍵盤操作、焦點和螢幕閱讀器。
Chrome 135 開始支援可自訂的 select。透過 appearance: base-select 和 ::picker(select)，下拉面板、箭頭、選項內容都能進一步調整，option 裡也能放入較豐富的內容。
目前仍要留意其他瀏覽器的支援情況，好消息是它採漸進增強：不支援新功能的瀏覽器，仍可顯示普通的原生 select。這比直接換成一個完全自製的下拉元件安心不少。
最基本的寫法
select,
select::picker(select) {
appearance: base-select;
}兩個 selector 都要設定：第一個是頁面上的按鈕，第二個是展開後的選項面板。進入 base-select 模式後，picker 會進到 top layer，也能搭配 Anchor Positioning。以前下拉選單常遇到被 overflow: hidden 切掉的問題，瀏覽器現在連這部分都一起處理。
不過它還不是「所有瀏覽器都放心用」的功能，手機上原生選單的操作感也可能比較符合使用者習慣。我的看法是先保留語意正確的 select，把客製樣式當成額外加分。就算新 CSS 沒生效，表單還是能正常選，這才是原生元件最大的優勢。
實作時我還會多做一個很土法煉鋼的檢查：只用鍵盤把表單走一遍，再開螢幕閱讀器聽一次選項。可自訂不代表瀏覽器會替所有設計決定收尾，例如 option 裡塞了圖示、次要文字和狀態標籤後，視覺上更豐富，朗讀順序卻可能變得很囉嗦。
這也是我不太想把 select 做成「越像一般 div 越好」的原因。原生控制項的價值就在於它有平台行為，尤其手機會提供熟悉的選取介面。品牌一致性當然重要，但如果為了統一圓角和陰影，換來一套要自己維護十年的鍵盤互動，這筆帳通常沒有想像中划算。