Select personalizzabile in Safari 27.2: selectedcontent, ::field-content e cosa controllare prima di usarlo
Con Safari 27.2 il select stilizzabile ha ora due strumenti per controllare il testo mostrato nel pulsante. Che cosa cambia, dove funziona e quali comportamenti cambiano quando si attiva base-select.
Per anni il tag select è stato uno dei pochi elementi di un form che si poteva stilizzare solo in parte. Il menu a tendina apparteneva al sistema operativo, e chi voleva icone, immagini o layout diversi nelle opzioni finiva per riscrivere tutto in JavaScript.
Il select personalizzabile cambia questa situazione, e il 26 ottobre 2026 WebKit ha pubblicato le novità di Safari 27.2 che ne rifiniscono l'uso.
Che cosa è successo
Il post WebKit Features for Safari 27.2, firmato da Jen Simmons e datato 26 ottobre 2026, spiega che il Customizable Select è arrivato in Safari 27.0. Da allora il lavoro sugli standard ha precisato alcuni dettagli e le implementazioni si stanno adeguando. In Safari 27.2 le novità per questo elemento sono tre: l'elemento <selectedcontent> come strumento per controllare cosa compare nel pulsante, il nuovo pseudo-elemento ::field-content, e alcune modifiche agli stili predefiniti di appearance: base-select.
Come si presenta il markup
Normalmente l'opzione scelta appare nel pulsante del select. Con <selectedcontent> si decide cosa mostrare e come. L'esempio del post WebKit è questo:
<select id="status">
<button>
<selectedcontent></selectedcontent>
</button>
<option>Processing</option>
<option>Shipped</option>
<option>Delivered</option>
<option>Canceled</option>
</select>
L'elemento è facoltativo. Il markup tradizionale, con le sole option dentro il select, continua a funzionare. Questo conta per la compatibilità: puoi partire dal select che hai già e aggiungere il pulsante solo dove serve.
Il nuovo ::field-content, disponibile da 27.2, permette invece di stilizzare il testo mostrato dell'opzione selezionata senza dover aggiungere <selectedcontent>. Il post non fornisce un esempio di sintassi per questo pseudo-elemento, quindi prima di usarlo conviene controllarne la forma nella specifica o nella documentazione MDN.
Che cosa cambia negli stili predefiniti
WebKit elenca queste modifiche allo stile del browser per appearance: base-select:
- il contenuto del pulsante si centra in verticale in modo più affidabile;
- il testo dell'opzione selezionata eredita
text-overflowdal select; - il layout di
::picker-iconè stato semplificato, e il suo contenuto predefinito è ora un glifo che non richiede margini negativi; - il pulsante usa
flex: 1al posto dimargin-inline-start: autosull'icona, quindi l'icona resta visibile anche senza<selectedcontent>.
C'è anche un cambiamento di posizionamento: i picker molto grandi potevano finire in parte fuori dal viewport, e Safari 27.2 applica l'allineamento safe per tenerli visibili. Per i box con posizionamento assoluto o fisso, safe li mantiene dentro il blocco contenitore originale. Le parole chiave safe e unsafe possono ora essere combinate con l'allineamento normal. Tra i 20 bug fix della release ce n'è anche uno che riguarda un elemento con anchor positioning dentro un dialog modale, che finiva fuori schermo e invisibile allo scroll.
Dove funziona oggi
Chrome ha introdotto il select personalizzabile con Chrome 135, come racconta l'articolo di Chrome for Developers del 24 marzo 2025, The <select> element can now be customized with CSS. Lo stesso articolo spiega che tutti i browser hanno partecipato al lavoro sulle specifiche. I dati di supporto di Can I use, consultati il 2 novembre 2026, indicano questo quadro per appearance: base-select:
- Chrome: supportato dalla 135;
- Edge: supportato dalla 135;
- Safari: supportato dalla 27;
- Firefox: non supportato fino alla 148, poi presente ma disattivato di default dalla 149 alla 162, ultima versione elencata.
In pratica oggi puoi contare su Chromium e Safari, mentre su Firefox gli utenti vedranno il select standard. Non ho verificato in modo indipendente la compatibilità di <selectedcontent> e ::field-content nei browser diversi da Safari 27.2: il post di Chrome non menziona selectedcontent, e il comportamento in Chrome dopo i recenti allineamenti alle specifiche va controllato sulla documentazione aggiornata.
Cosa succede nei browser che non lo supportano
Secondo Chrome for Developers la funzione non rompe i browser più vecchi: se il browser non conosce base-select, le immagini o le icone messe dentro le option non vengono mostrate e il select appare come prima. L'articolo mostra Safari e Firefox, all'epoca della pubblicazione, che rendono l'esempio senza le icone.
Un modo ragionevole per sfruttare questo comportamento è fare in modo che le informazioni importanti stiano nel testo dell'opzione e che le icone siano solo un rinforzo, nascoste a livello accessibile con aria-hidden, come negli esempi di Chrome. Per limitare la personalizzazione ai browser compatibili si può racchiudere il CSS in una condizione @supports (appearance: base-select). Questa è una mia indicazione, non tratta dalle fonti, e non l'ho testata sul campo.
@supports (appearance: base-select) {
select,
select::picker(select) {
appearance: base-select;
}
}
Il selettore combinato nel blocco segue l'esempio di Chrome for Developers.
Cosa si perde attivando base-select
Qui c'è la parte che pesa di più sulle decisioni di progetto. L'articolo di Chrome ricorda che con base-select alcuni comportamenti predefiniti vengono meno: il select non viene più renderizzato fuori dal riquadro del browser, non attiva più i componenti del sistema operativo mobile e non si dimensiona più sull'opzione più lunga. Se sul tuo sito il select nativo mobile era un vantaggio, quel vantaggio sparisce dove attivi la personalizzazione.
C'è poi un avviso sul valore selezionato. Chrome segnala che la logica con cui viene calcolata la stringa dell'opzione selezionata è cambiata quando nelle option c'è HTML ricco, e consiglia di verificare i valori e di usare l'attributo value. Se il tuo JavaScript legge il testo dell'opzione invece del valore, qui potresti trovare sorprese.
Quando conviene usarlo
La scelta dipende dal tipo di select. Per un filtro di stato, un selettore di lingua o un menu di ordinamento, dove icone e layout aiutano a riconoscere le voci, il select personalizzabile sostituisce volentieri una libreria di dropdown costruita a mano, con il vantaggio di mantenere l'elemento nativo e il suo comportamento da tastiera. Per un select lungo e semplice, dove l'interfaccia nativa mobile funziona bene, la personalizzazione porta poco e fa perdere qualcosa.
Un buon test prima del rilascio comprende: il select standard in Firefox, l'uso da tastiera, la lettura del valore selezionato dal JavaScript esistente e il comportamento su mobile.
Limiti di questo articolo
Il codice mostrato non è stato eseguito. Il supporto di Firefox arriva da Can I use e non da una fonte del produttore. La sintassi di ::field-content non è riportata nel post WebKit.
Fonti
- WebKit Blog, Jen Simmons, “WebKit Features for Safari 27.2”, 26/10/2026
- Chrome for Developers, “The <select> element can now be customized with CSS”, 24/03/2025
- Can I use, “appearance: base-select”, consultato il 02/11/2026