Il design di select funzionalità in Materialise CSS è, a mio parere, una buona ragione per non usarlo.
Devi inizializzare l'elemento select con material_select() , come menzionato da @ littleguy23. In caso contrario, la casella di selezione non viene nemmeno visualizzata! In un'app jQuery vecchio stile, posso inizializzarla nella funzione document ready. Indovina un po ', né io né molte altre persone usiamo jQuery in questi giorni, né inizializziamo le nostre app nell'hook document ready.
Selezioni create dinamicamente . E se creo selezioni dinamicamente, come accade in un framework come Ember che genera visualizzazioni al volo? Devo aggiungere la logica in ogni vista per inizializzare la casella di selezione ogni volta che viene generata una vista, o scrivere un mixin di vista per gestirlo per me. Ed è peggio di così: quando la vista viene generata, e in termini di Ember didInsertElementviene chiamata, l'associazione all'elenco delle opzioni per la casella di selezione potrebbe non essere stata ancora risolta, quindi ho bisogno di una logica speciale che osservi l'elenco delle opzioni per aspettare finché non è popolato prima di effettuare la chiamata al material_select. Se le opzioni cambiano, come potrebbero facilmente, material_selectnon ne ha idea e non aggiorna il menu a discesa. Posso chiamarematerial_select nuovo quando le opzioni cambiano, ma sembra che ciò non faccia nulla (viene ignorato).
In altre parole, sembra che l'ipotesi progettuale dietro le caselle di selezione di materialize CSS sia che siano tutte presenti al caricamento della pagina e che i loro valori non cambino mai.
Implementazione . Da un punto di vista estetico, inoltre, non sono favorevole al modo in cui materializzare CSS implementa i suoi menu a discesa, che consiste nel creare un insieme ombra parallelo di elementi da qualche altra parte nel DOM. Certo, alternative come select2 fanno la stessa cosa e potrebbe non esserci altro modo per ottenere alcuni degli effetti visivi (davvero?). Per me, però, quando ispeziono un elemento, voglio vedere l'elemento, non una versione ombra da qualche altra parte che qualcuno ha creato magicamente.
Quando Ember abbatte la vista, non sono sicuro che materializzare CSS abbatti gli elementi ombra che ha creato. In realtà, sarei piuttosto sorpreso se lo facesse. Se la mia teoria è corretta, man mano che le visualizzazioni vengono generate e abbattute, il tuo DOM finirà per essere inquinato da dozzine di set di menu a discesa ombra non collegati a nulla. Ciò si applica non solo a Ember ma a qualsiasi altro framework front-end OPA basato su MVC / template.
Binding . Inoltre, non sono stato in grado di capire come ottenere il valore selezionato nella finestra di dialogo per collegarmi a qualcosa di utile in un framework come Ember che richiama le caselle di selezione tramite un'interfaccia di {{view 'Ember.Select' value=country}}tipo. In altre parole, quando qualcosa è selezionato, countrynon viene aggiornato. Questo è un rompicapo.
Onde . A proposito, gli stessi problemi si applicano all'effetto "onda" sui pulsanti. Devi inizializzarlo ogni volta che viene creato un pulsante. Personalmente non mi interessa l'effetto onda e non capisco di cosa si tratta, ma se vuoi le onde, sii consapevole che trascorrerai buona parte del resto della tua vita a preoccuparti di come farlo inizializza ogni singolo pulsante quando viene creato.
Apprezzo lo sforzo fatto dai ragazzi di materializzare CSS, e ci sono alcuni bei effetti visivi lì, ma è troppo grande e ha troppi trucchi come quello sopra per essere qualcosa che userei. Ora sto pianificando di estrarre materializzare CSS dalla mia app e tornare a Bootstrap o un livello sopra Suit CSS. I tuoi strumenti dovrebbero semplificarti la vita, non più difficile.
<select class="browser-default">