Select personalizzabile con CSS: cosa usare oggi (base-select)

Il menu a tendina è uno dei componenti che i design system ricostruiscono più spesso da zero. Il motivo è noto: il select nativo si lasciava stilizzare a malapena, quindi si sostituiva con un insieme di div e JavaScript, per poi rincorrere tastiera, lettori di schermo e comportamento su mobile. Il 17 settembre 2026 WebKit ha pubblicato le novità di Safari 27.0, e tra queste c'è la personalizzazione del select via CSS. Vale la pena capire cosa si può fare già oggi con appearance: base-select, cosa si perde e dove serve prudenza.

Come si attiva la personalizzazione

L'opt-in è una sola dichiarazione, da applicare sia al select sia al suo menu, che si indirizza con ::picker(select):

CSS

select,
select::picker(select) {
  appearance: base-select;
}

Nella guida di Chrome for Developers, pubblicata il 24 marzo 2025 in occasione di Chrome 135, si spiega cosa cambia dietro le quinte. Il browser modifica il parsing del contenuto del select, espone nuove parti e stati, e mostra le opzioni nel top layer con posizionamento ancorato. Il vantaggio più visibile è che dentro un <option> ora si possono mettere immagini e SVG, che prima venivano ignorati.

La struttura HTML consigliata da MDN prevede un pulsante con <selectedcontent> come primo figlio del select, che mostra il contenuto dell'opzione selezionata. Per lo stile ci sono ::picker-icon per l'icona, ::checkmark per la spunta, :open per lo stato aperto e :checked per l'opzione scelta. Si può anche animare l'apertura con @starting-style e posizionare il menu con le funzioni di anchor positioning.

Safari 27.0 aggiunge stili predefiniti rivisti: angoli arrotondati di 4px, altezza di riga adatta al tocco, stati hover più puliti, chevron e spunta già pronti, oltre al supporto per tema chiaro e scuro, forced colors e stato disabilitato. WebKit li presenta come un punto di partenza da sovrascrivere.

Cosa resta nativo e cosa si perde

Secondo WebKit il controllo mantiene tastiera, lettori di schermo, invio del form, validazione ed evento change, quindi non serve reimplementarli. Il prezzo, elencato da Chrome for Developers, è di tre cose: il menu non può più uscire dal riquadro del browser, non viene attivato il componente del sistema operativo mobile e la larghezza non si calcola più in automatico sull'opzione più lunga. Se il tuo select si affida a quel comportamento su mobile, è un cambio da mettere in conto.

Fallback: cosa succede nei browser che non lo supportano

MDN descrive il comportamento con precisione. I browser che non supportano la funzione ignorano la struttura con pulsante e <selectedcontent> e riducono il contenuto delle opzioni ai soli nodi di testo. Il risultato è un select classico e funzionante. Questo però regge solo se il testo c'è sempre. È la "regola d'oro" formulata da WebKit in un post del 15 giugno 2026: fornire sempre testo o attributi accessibili per le opzioni, e racchiudere i miglioramenti in @supports (appearance: base-select), lasciando il testo semplice come base.

HTML

<option>
  <img src="bird.svg" alt="">
  <span>Wildlife</span>
</option>

L'icona è un'aggiunta, il testo resta. Se serve, il testo può essere nascosto alla vista con una classe di tipo visually-hidden ma deve restare disponibile a tecnologie assistive.

I limiti da verificare prima di adottarlo

MDN indica che la funzione non è Baseline, perché non è disponibile in alcuni browser molto diffusi. Su Firefox il quadro è meno chiaro: il bug tracker di Mozilla segna l'implementazione di appearance: base-select come risolta per Firefox 149, ma dietro la preferenza layout.css.appearance-base-select.enabled. Non ho trovato una conferma che sia attiva di default, quindi controlla la tabella di compatibilità aggiornata prima di decidere.

Ci sono poi tre avvertenze pratiche riportate da MDN. Alcuni framework JavaScript bloccano queste funzioni o causano errori di hydration con il rendering lato server. Il contenuto generato con content su ::checkmark e ::picker-icon non entra nell'albero di accessibilità. La guida copre solo il select singolo, non quello a selezione multipla. Chrome for Developers aggiunge che, essendo le immagini e gli SVG ignorati nel determinare il valore, conviene testare i valori selezionati. Infine WebKit ricorda che l'implementazione è ancora in raffinamento presso il CSS Working Group, quindi dettagli della sintassi potrebbero cambiare.

Quando conviene adottarlo

Questa parte è una valutazione mia, non una raccomandazione delle fonti. Il caso più solido è un progetto in cui il select è un elemento del design system e il pubblico usa in gran parte Chrome e Safari, dove la perdita di un componente JavaScript da mantenere ha un valore reale. Prima di sostituire tutto, provo su un solo componente e controllo quattro cose:

ogni opzione ha testo leggibile anche senza icona;
gli stili avanzati sono dentro @supports (appearance: base-select);
il framework e il rendering lato server non rompono la struttura con <selectedcontent>;
il comportamento su mobile, senza il componente di sistema, è accettabile per i tuoi utenti.

Se una di queste risposte è no, il select nativo classico resta una scelta ragionevole, e il fallback descritto sopra ti permette di introdurre il miglioramento in modo graduale.

Fonti

WebKit Blog, “Customizable Select in Safari 27.0”, 17 settembre 2026
WebKit Blog, “The golden rule of Customizable Select”, 15 giugno 2026
Chrome for Developers, “The select element can now be customized with CSS”, 24 marzo 2025
MDN, “Customizable select elements”, consultata il 29 settembre 2026
Mozilla Bugzilla, “bug 1974787”, consultato il 29 settembre 2026