Il 14 settembre 2026 Apple ha rilasciato iOS 27 e con lui Safari 27, che porta la select personalizzabile via CSS. Chrome ed Edge ce l’hanno stabile dalla versione 135. Sono due motori su tre, e il grosso della copertura lo porta Chrome, stabile da aprile 2025, non Safari uscito ieri. Cambia una cosa concreta per chi gestisce siti WordPress: la libreria JavaScript caricata su ogni pagina per far sembrare decente una tendina di un form è codice che non serve più. Togliergliela è un lavoro da mezz’ora, e si fa senza rompere niente.

Quanto costa davvero una tendina finta

Select2, Choices.js e i loro cloni fanno tutti la stessa cosa: nascondono la <select> vera e disegnano al suo posto un <div> con una lista di <li>. Da lì in avanti tutto quello che il browser ti dava gratis va riscritto a mano: navigazione da tastiera, annuncio allo screen reader, gestione del focus, validazione HTML, evento change. Alcune librerie lo fanno bene, molte no, e il plugin che te l’ha portata in casa non ha scelto in base all’accessibilità. Il costo secondario è il peso: Select2 si porta dietro jQuery, e nei siti WordPress reali viene messo in coda su tutte le pagine, non solo su quelle che hanno un form. È lo stesso schema che ho descritto per i chatbot e i Core Web Vitals: uno script che serve a una pagina su venti viene pagato da venti pagine su venti. La differenza è che lì lo script una funzione la fa, qui sta ridisegnando un controllo che il browser disegna da solo.

La select vera, stilizzata con i CSS

Il meccanismo è una sola proprietà. appearance: base-select mette la <select> in uno stato nuovo, senza lo stile imposto dal sistema operativo, e da lì la stili come un qualsiasi elemento. Va messa due volte: sul controllo e sullo pseudo-elemento ::picker(select), che è il pannello che si apre. All’interno hai ::picker-icon per la freccia e ::checkmark per la spunta accanto all’opzione scelta. C’è anche <selectedcontent>, che rispecchia nel controllo chiuso il contenuto dell’opzione selezionata, markup compreso: è l’unico pezzo della feature che chiede markup in più, perché va messo dentro un <button> figlio della <select>.

@supports (appearance: base-select) {
  select, ::picker(select) { appearance: base-select; }
  select {
    border: 1px solid #c8cdd6;
    border-radius: 8px;
    padding: .6rem .9rem;
    font: inherit;
  }
  ::picker(select) { border-radius: 8px; box-shadow: 0 8px 24px rgb(0 0 0 / .12); }
  option::checkmark { color: #1a73e8; }
}

Con il CSS qui sopra il markup HTML non cambia di una riga: resta <select> con i suoi <option>, quindi invio del form, validazione ed eventi continuano a funzionare come prima, perché il controllo è ancora quello vero. Il blocco @supports non è cautela formale: dove la proprietà non esiste, il CSS interno viene ignorato in blocco e resta la tendina di sistema, intatta. È progressive enhancement vero, non un fallback scritto a parte che poi qualcuno dimentica di aggiornare. E la sintassi è concordata tra i motori, non un’estensione Apple o Google: quello che scrivi oggi per Safari 27 vale già per Chrome, e varrà per Firefox senza riscritture.

Come si innesta su un sito WordPress

Tre passaggi, nell’ordine. Primo: trova chi carica la libreria. Nella maggior parte dei casi è un plugin di form o un tema, e lo vedi con wp_print_scripts o semplicemente guardando gli handle in pagina: select2, selectWoo, choices. Secondo: scrivi il CSS dentro @supports nel foglio di stile del child theme, non nel customizer e non in un plugin di snippet: è stile, deve stare col tema e seguirlo negli aggiornamenti. Terzo: rimuovi lo script solo dove il markup sotto è già una <select> nativa, con un wp_dequeue_script() agganciato a wp_enqueue_scripts con priorità tarda (add_action('wp_enqueue_scripts', 'mio_dequeue', 100): numero alto vuol dire esecuzione dopo, e lo script lo puoi togliere solo dopo che il plugin lo ha accodato) e condizionato alla pagina. Contact Form 7 usa il controllo nativo, e così WPForms se il campo Dropdown non è impostato sullo stile Moderno, che carica Choices.js; molti temi invece avvolgono la select in un wrapper proprio, e lì il dequeue lascia il controllo nudo ma funzionante, che è già meglio di quello che avevi. Verifica su Safari 27, su Chrome e su Firefox, che ancora non ha la proprietà e deve mostrarti la tendina di sistema intatta.

L’errore da evitare, e cosa fare oggi

L’errore è trattare tutte le select allo stesso modo e togliere la libreria anche dove fa una funzione, non una decorazione. Il caso tipico è il checkout WooCommerce: il selettore del paese ha oltre duecento voci e selectWoo ci aggiunge un campo che filtra le opzioni mentre digiti. La select nativa il salto per iniziale ce l’ha già, e appearance: base-select non glielo toglie; quello che manca è la ricerca per sottostringa su una lista lunga, e i CSS non te la danno. Togli la libreria dai form di contatto, dai filtri con cinque opzioni, dalle select di un campo “come ci hai trovato”; lasciala dove è l’unica cosa che rende usabile una lista lunga. La distinzione è la stessa che vale per i controlli sui form WordPress: si toglie quello che è abitudine, si tiene quello che risolve un problema che esiste davvero. Il guadagno non è estetico ma di manutenzione: una dipendenza in meno da aggiornare, e un punto in meno dove l’accessibilità si rompe in silenzio. Mezz’ora sul form principale del sito, oggi: quello da cui arrivano i preventivi.

Fonti: WebKit, News from WWDC26: WebKit in Safari 27 beta; Apple Developer, Safari 27 Release Notes; Chrome for Developers, The select element can now be customized with CSS.