На select
мой взгляд, создание функциональности в материализованном CSS - это довольно веская причина не использовать его.
Вы должны инициализировать элемент select с помощью material_select()
, как упоминает @ littleguy23. Если вы этого не сделаете, поле выбора даже не отобразится! В старомодном приложении jQuery я могу инициализировать его в функции готовности документа. Угадайте, что ни я, ни многие другие люди в наши дни не используют jQuery, и мы не инициализируем наши приложения в ловушке готовности документа.
Динамически созданные выборки . Что, если я создаю выборки динамически, например, в такой среде, как Ember, которая генерирует представления на лету? Мне нужно добавить логику в каждое представление, чтобы инициализировать поле выбора каждый раз, когда представление создается, или написать миксин представления, чтобы обрабатывать это за меня. И еще хуже: когда создается представление и вызывается в терминах Ember didInsertElement
, привязка к списку параметров для поля выбора, возможно, еще не решена, поэтому мне нужна специальная логика, наблюдающая за списком параметров, чтобы ждать, пока он заполняется перед вызовом material_select
. Если параметры меняются, что легко может быть, material_select
не знает об этом и не обновляет раскрывающийся список. Я могу позвонить material_select
снова, когда параметры меняются, но, похоже, это ничего не делает (игнорируется).
Другими словами, похоже, что проектное предположение, лежащее в основе материализованных полей выбора CSS, заключается в том, что все они присутствуют при загрузке страницы, и их значения никогда не меняются.
Реализация . С эстетической точки зрения, я также не сторонник того, как материализация CSS реализует свои раскрывающиеся списки, то есть для создания параллельного теневого набора элементов где-то еще в DOM. Конечно, альтернативы, такие как select2, делают то же самое, и может не быть другого способа добиться некоторых визуальных эффектов (правда?). Однако для меня, когда я проверяю элемент, я хочу видеть этот элемент, а не какую-то теневую версию где-то еще, которую кто-то волшебным образом создал.
Когда Ember срывает представление, я не уверен, что материализация CSS срывает созданные им теневые элементы. На самом деле, я был бы очень удивлен, если бы это произошло. Если моя теория верна, поскольку представления генерируются и удаляются, ваша DOM в конечном итоге будет загрязнена десятками наборов раскрывающихся списков теней, не связанных ни с чем. Это относится не только к Ember, но и к любой другой интерфейсной платформе OPA на основе MVC / шаблонов.
Привязки . Я также не смог понять, как получить значение, выбранное в диалоговом окне, для привязки к чему-либо полезному в такой платформе, как Ember, которая вызывает поля выбора через {{view 'Ember.Select' value=country}}
интерфейс типа. Другими словами, когда что-то выбрано, country
не обновляется. Это нарушитель сделки.
Волны . Кстати, те же проблемы касаются эффекта «волны» на кнопках. Вы должны инициализировать его каждый раз, когда создается кнопка. Меня лично не волнует волновой эффект, и я не понимаю, о чем идет речь, но если вам действительно нужны волны, имейте в виду, что вы потратите значительную часть остатка своей жизни, беспокоясь о том, как инициализировать каждую кнопку при ее создании.
Я ценю усилия, приложенные ребятами из Materialise CSS, и там есть несколько хороших визуальных эффектов, но он слишком велик и содержит слишком много подводных камней, таких как вышеупомянутый, чтобы я мог использовать его. Теперь я планирую вырвать материализацию CSS из своего приложения и вернуться либо к Bootstrap, либо к слою поверх Suit CSS. Ваши инструменты должны облегчить вам жизнь, а не усложнить ее.
<select class="browser-default">