O design de selectfuncionalidade em materializar CSS é, na minha opinião, um bom motivo para não usá-lo.
Você tem que inicializar o elemento select com material_select(), como @ littleguy23 menciona. Caso contrário, a caixa de seleção nem mesmo será exibida! Em um aplicativo jQuery antigo, posso inicializá-lo na função de documento pronto. Adivinhe, nem eu nem muitas outras pessoas estão usando jQuery atualmente, nem inicializamos nossos aplicativos no gancho pronto para documentos.
Seleções criadas dinamicamente . E se eu estiver criando seleções dinamicamente, como acontece em uma estrutura como o Ember, que gera visualizações instantaneamente? Eu tenho que adicionar lógica em cada visão para inicializar a caixa de seleção toda vez que uma visão é gerada, ou escrever um mixin de visão para lidar com isso para mim. E é pior do que isso: quando a visualização é gerada, e em termos de Ember didInsertElementé chamada, a ligação com a lista de opções para a caixa de seleção pode não ter sido resolvida ainda, então eu preciso de uma lógica especial observando a lista de opções para esperar até que seja preenchido antes de fazer a chamada para o material_select. Se as opções mudarem, como poderiam facilmente, material_selectnão tem ideia sobre isso e não atualiza o menu suspenso. Posso ligar material_selectnovamente quando as opções mudam, mas parece que isso não faz nada (é ignorado).
Em outras palavras, parece que a suposição de design por trás de materializar as caixas de seleção do CSS é que todas elas estão lá no carregamento da página e seus valores nunca mudam.
Implementação . Do ponto de vista estético, também não sou a favor da maneira como o CSS implementa seus dropdowns, que é criar um conjunto paralelo de elementos de sombra em algum outro lugar do DOM. Concedido, alternativas como select2 fazem a mesma coisa, e pode não haver outra maneira de obter alguns dos efeitos visuais (sério?). Para mim, porém, quando inspeciono um elemento, quero ver o elemento, não alguma versão de sombra em algum outro lugar que alguém criou magicamente.
Quando o Ember destrói a visualização, não tenho certeza se o CSS materializar destrói os elementos de sombra que ele criou. Na verdade, eu ficaria muito surpreso se isso acontecesse. Se minha teoria estiver correta, conforme as visualizações são geradas e destruídas, seu DOM vai acabar ficando poluído com dezenas de conjuntos de dropdowns de sombra não conectados a nada. Isso se aplica não apenas ao Ember, mas a qualquer outra estrutura de front-end OPA baseada em MVC / template.
Ligações . Eu também não consegui descobrir como obter o valor selecionado na caixa de diálogo para vincular de volta a qualquer coisa útil em uma estrutura como o Ember, que invoca caixas de seleção por meio de uma {{view 'Ember.Select' value=country}}interface de tipo. Em outras palavras, quando algo é selecionado, countrynão é atualizado. Este é um quebra-negócio.
Waves . A propósito, os mesmos problemas se aplicam ao efeito de "onda" nos botões. Você deve inicializá-lo sempre que um botão for criado. Eu, pessoalmente, não me importo com o efeito das ondas e não entendo o porquê de tanto barulho, mas se você quiser ondas, esteja ciente de que passará boa parte do resto da sua vida se preocupando em como inicializar cada botão quando ele for criado.
Agradeço o esforço feito pelos caras do CSS para materializar, e há alguns efeitos visuais legais lá, mas é muito grande e tem muitos truques como os acima para ser algo que eu usaria. Agora estou planejando extrair materializar CSS do meu aplicativo e voltar para o Bootstrap ou uma camada em cima do CSS do Suit. Suas ferramentas devem tornar sua vida mais fácil, não mais difícil.
<select class="browser-default">