Hello
I just begin with Material design lite, and it's awesome. But i miss something et i didn't find it in the documentation.
I'm working on a form, and i didn't find a way to have good select input. (I find text/number input, checkbox, radio button, ...)
Someone can help me?
Thank you
Thomas
@Bamertos Select, is just standard HTML select elements. Right now we have no guidance on how selects should look, other than chip systems which is a planned addition and we could build off from that.
We should get in touch with the MD team on how to proceed in the best way.
On the note of simply needing more form components, please file specific issues and use-cases. The more actionable and specific items we have to work on the better.
@Garbee What about this? It's look like a Select input

Oh nice catch. It is placed under Menus... Ok, good enough for me. I'll bring it up when we start planning new component additions. One thing is, we could also want to support chips under selects for an advanced view for dropdowns (since they could be interchangeable specs for the task.)
EDIT: And leaving guidance task just as a reminder to verify with the MD team that this is a valid use-case. Looks like it should be, but better safe than sorry when implementing.
@Rom4eg Where did you find that example with the address input? I've been trying to figure out how to do a dropdown as well and that would work fine for me, but I cannot find the example that shows that interface and how to create it.
@adammhaile That is from the Material Design specification. MDL has yet to implement that functionality. For now it will need to be a custom implementation.
Ahhh... OK. That's unfortunate. Thanks for clarifying. I'll just have to
wait on MDL for now :)
On Thu, Jul 9, 2015 at 11:14 AM, Jonathan Garbee [email protected]
wrote:
@adammhaile https://github.com/adammhaile That is from the Material
Design specification. MDL has yet to implement that functionality. For now
it will need to be a custom implementation.—
Reply to this email directly or view it on GitHub
https://github.com/google/material-design-lite/issues/854#issuecomment-120027938
.
I thought it is bad to break the default select implement from the browser.
Since browsers implement it in multi ways.
On mobile, they implement it as overlay.(dropdown doesn't really fit to a mobile device.)
On desktop, they implement it as dropdown menu.
The HTML spec doesn't actually tell us how to implement it.
Just like ...etc.
The tag is defined by its meaning, not look.
If we must implement it, then we need to implement all types of layout of every browsers for the best accessibility.
It would be very complex.
We can style desktop systems a bit and leave mobile to act as it normally would.
Makes sense to me. Select is used a lot and it would be a shame to have it
missing.
On Sat, Jul 11, 2015 at 10:10 AM, Jonathan Garbee [email protected]
wrote:
We can style desktop systems a bit and leave mobile to act as it normally
would.—
Reply to this email directly or view it on GitHub
https://github.com/google/material-design-lite/issues/854#issuecomment-120624940
.
@Garbee
http://jsbin.com/salutaroku/1/edit?html,css,output
You means, just change the look but don't touch its function on mobile?
@mmis1000 Yes, it should be doable. What is the point behind the jsbin?
just a small example for customized look select element
that is an accepted bug, please stop adding "+1" to it.
hit the subscribe button in the sidebar if you want to track progress.
Hey guys, is anyone working on this?
I could help out. Do you guys have a chat or something?
In the meantime I made my own "css only"-version (simple) http://codepen.io/pudgereyem/pen/PqBxQx/
If you want a Javascript-version that styles the whole thing, I would recommend http://materializecss.com/forms.html or http://semantic-ui.com/modules/dropdown.html
Btw, it seems like Angular Material have implemented this already; https://material.angularjs.org/latest/#/demo/material.components.select
i just clone Textfield js and css code into a new one and it works in chrome but not perfect.
waiting for the official dropdown component.
http://codepen.io/etcpe9/pen/PqyOye
I've started work on adding this to MDL, should I make a pull request?
@langan Awesome! I’d be happy to look over your pull request :)
Ive pushed my code to a branch on my fork
https://github.com/langan/material-design-lite/commit/ddd169c77ad132590ce5d52f4cf90d8383ab349b
It's my first attempt at anything on this project so let me know if it looks ok and if its worth continuing (would be happy to work on it further and add an example component page)
@langan Don’t be afraid to open up a proper PR. That we’ll have an isolated thread for discussion and review
More examples can be found in Polymer and Angular-Material
Hello !
+1
It would have been really usefull to have it.
Thanks
:+1:
I have create a prototype of dropdown by combining mdl-textfield and mdl-button. Selecting a value is not working for now. I am working on it.
http://codepen.io/kushdilip/pen/bVbXgJ?editors=110
@etcpe9 very good man!!!
Thanks!!
Excuses like "we have no guidance on how selects should look" fall short of the getmdl.io statement "Material Design Lite lets you add a Material Design look and feel to your websites.".
Polymer and other web-based material design libraries are pushing ahead.
https://elements.polymer-project.org/elements/paper-dropdown-menu?active=paper-dropdown-menu&view=demo:demo/index.html
+1
For those who are interested, I developed a plugin and added it to bower:
@mebibou could you add a codepen, plunker or similar, or simply an example page within your project?
Post edit: @Garbee understood and agreed. Actually it was what I did after comenting.
@davidpelayo Please bring up issues with @mebibou's package on _their_ repository. Comments on this PR should be constructive towards making sure it is ready to be accepted, not discussion about other projects.
Hi guys, not trying to over pushing this issue, just wondering how the progress from Dev.
I already look upon @mebibou selectfield, it's awesome and probably I would use that for the moment, still it would be awesome if this feature added soon :)
Hey @ksugiarto I am not sure if anyone has started work on one yet, are you or @mebibou interested in opening up a PR? That would be super awesome! Thanks for the interest
hi @samccone after scrolling upside down, I read that actually @langan already fork and work on some cool code, would be awesome if this code could be fully develop.
@ksugiarto @samccone yes the one I did is a standard html select, so that on mobile phones it uses the standard select behaviour and not some dropdown that would appear on the screen, which it would be harder to use and control the look. Therefore it probably doesn't go along the material design specs (if they are any for this component), which is why I don't plan on making a PR, but I'm open to suggestions :)
A PR is already open for one method of doing select inputs. However, there are a few methods we could take here. Before anything is accepted in we need to think through the accessibility. I need to sit down and run through tests of different methods and see how accessible they are, especially on mobile. This is going to take quite a bit of time, which is why no more movement has been made on the open PR. Finding the time to sit down and dig into a11y is difficult with everything else I have going on.
tl;dr
Don't expect it in 1.1. A11y is extremely important and we need to make sure it is done well.
hi @Garbee wow, thanks so much. Me personally not trying to pushing something to you guys, and I know for sure make a simple mvp feature would be easy for you guys, but for make it sure really work in every kind of conditions, that one big thing.
But the things that I believe people here also want you guys to know that we are so enthusiastic for this feature :D thanks in advance
that tell about it https://github.com/MEYVN-digital/mdl-selectfield ?
Hey @Garbee @samccone
is this still relevant for adding pull request?
from what i understand there's a method for mobile and one for desktop?
i have some basic react prototype
http://codepen.io/upmhh20/pen/vLyZZQ
There currently is one PR for this (addressing that in a moment.)
Essentially, due to select being a manipulation on top of a form object we are most likely going to end up handling this among the core team (probably myself) after 2.x is released.
We want to make sure that whatever is included is not violating accessibility. Which every current proposal does do since they all depend upon our menu system which is not fully accessible yet.
If someone can build a proposal (post 2.x since doing it against 1.x is not going to be a good use of effort) that doesn't break accessibility, then they are free to go for it otherwise.
The main difference from the spec is, on mobile we are going to try and use the native select handlers. Then on desktops use the MD menu style.
@Garbee what do u mean for violating accessibility in this case? And had you thought about creating a "lab/extras" repository for components that can not be included in mdl right now, but may be in the future?
Violating a11y, I mean we shouldn't introduce a component that reduces a11y lower than the default element. i.e. Our menu component currently is not as accessible as a select element is, so it is a violation using that.
No other repo is going to get made at the moment for experiments. I'm working on planning breaking things out, but that is for another future major due to the increased workload and management of such a task.
Doing a purely experimental area is a bad idea. People then start using it in production as if it is sound and then complain when things break or users have problems. Also, support expectations. No matter how many times we say things aren't supported yet, people will still ask for help. Best avoid that situation entirely.
It would also mean, putting direct effort into doing _something_ when right now we have _nothing_ towards it. Which distracts from effort going into other areas. Overall, wasting effort when the full workload can be put in at once and the components can be given the attention they deserve.
This component is going to get worked on. Immediately however, we have many other bigger priorities that are affecting developers which the sooner we get solved the better. That way focusing on new components is a simpler effort as well once those changes are in.
Just pointing out that besides the usage in the example on the menu page, the actual element shown is documented as a dropdown button on the buttons documentation page: http://www.google.com/design/spec/components/buttons.html#buttons-dropdown-buttons
@gpgekko That is a peripheral thing that isn't really relevant. The spec is not worded for web tech, so they are just naming things whatever. We'd replace the select with a button/menu combination. But, it has more work involved then just drop in and replace. Also, doing things like that for developers is only going to be done as absolutely required in 2.x. So that makes rolling out an implementation more difficult.
@Garbee is there a roadmap for MDL releases?
Just the milestones on GH. However, they are not comprehensive and the dates are just picked out of air pretty much.
Look at getmdl-select - that's the thing you really need! It provides a fast way to make select input with native Material design lite menu style.
https://github.com/CreativeIT/getmdl-select
hope it'll help you
@franckevva great suggestion! Unfortunately I am using the
@Etabat You’ll probably have more success with these kinds of questions on StackOverflow using the material-design-lite tag. We try to keep the GH issue tracker for core issues only.
Hi there.. Just wanted to ask if anyone is currently tackling with this component? Any progress on having this one soon in "close-to-production" PR?
https://github.com/dgrubelic/material-design-lite/tree/selectfield
Since no one is actually doing anything on this component (if anyone is, please correct me), i started doing it on my own.
Here you can see early-development version of SelectField component. As usual, any comments, suggestions and issues, please write them down in my repo since this is my vision of select input component.
:+1: @franckevva thanks a lot for your implementation!!
Waiting for the official version now :)
I was looking at the implementation of @franckevva component, and although it is a nice solution, i don't think that it is a good way to address the problem of select input. The thing is that this is only textfield with menu component (and specs states "textfield with dropdown"). So there is no select element manipulation logic behind this component so there is no support for single or multiple selections.
Also, this component does not comply the rule:
"Positioning the menu below the emitting element separates it from its context.".
That was the main reason why i went with developing another solution. But then again, it's up to you to decide what you want to use in your app.
Unfortunately, other than gif there is no MD guideline how to really implement this feature.
Hey guys and girls... Anyone interesting for a little test drive of my SelectField component? Feedback would be very much appreciated before i submit official PR (since i have one more thing to implement, that could be this week).
Go to my repo, clone it and try it out. :)
So, in a discussion with @leifoolsen a question occurred to me? What happens with select element (regarding the behaviour and implementation itself) when multiple attribute set to true according to MD specs?
There are some mentions in Lists: controls section, but i can't figure out if that should be related to select element with multiple = true.
https://www.google.com/design/spec/components/lists-controls.html#lists-controls-types-of-menu-controls
A select component should comply with the semantics of a select element. If not, it's not a select element. For multiple choices, you might as well use a list with check boxes
So, you're saying that complete "multiple" state of select element should be ignored? So, on one side we should keep in mind to include accessibility at all cost but ignore one entire mode of element functionality? Sorry and no hard feelings, but that is ridiculous. I'd like to hear what MDL core team has to say on this...
Also, Angular Material is also supported by Google and they have implemented multiselect feature for select component just the way i did. How could Google have double standards for MD specs?
I'm not saying that you should not use the select element for multi select. As long as you follow the semantics there should be no problem with this. You have only two tags available, select and option, which puts a few restrictions on the design.
...and optgroup, which there is a task in my repo waiting for implementation. :smile:
I'm not saying that you should not use the select element for multi select
This being said, i guess my idea of component implementation does make sense. :smile:
@dgrubelic gave it a try and works like a charm! :smile:
@dgrubelic: I downloaded your selectfield component and put it into my build (Babel6). It works (to some extent) - but I'm experiencing the same issue as I reported in #4205; the ripple event i fires on the container. Do you have the same issue when running in your environment?
It works (to some extent)
What's not working? Please do know that this component is still in active development (working on option groups right now) so issues are possible. If you run into anything bad, please report it on my repo.
Actually, i don't have any issues with ripple container. You can check demos in /src/selectfield/demo.html - there is a working version of selectfield with ripple effect.
How can I run this? There is are no refs to CSS and JS in the demo
gulp all && gulp serve
then open: http://localhost:5000/components/selectfield/demo.html
Hmm.. I use NPM and Webpack. Must install Gulp first.
After looking into the gulp.babel.js I've found a possible cause for my Issue - see comment in #4205.
This is for my cloned repo. It uses gulp internally.
For one project i'm working on, i created another special repo where i "cook" my own MDL build. That build includes datepicker, selectfield, some custom color definitions, etc. But this is esentially clone of original MDL repo using all MDL infrastructure.
I'll come back with some feedback later this evening. Made a branch here: https://github.com/leifoolsen/mdl-ext/tree/evaluate/mdl-select
Think I can use that for testing.
I've tested a bit, although somewhat superficial yet. Here is a brief summary.
1: The popup list does not respect the browser viewport.

As you can observe from the screenshot the list is clipped - it should adjust "upwards" to show the list unclipped. This is the behavior of the select box.
2: No unit tests. Tests should be written in paralell with developing of the component.
3: Not "light weight". Too much code for a simple selcet element. No more code/functionality than is implemented for the MDL textfield should be required for this.
4: Dependency to the Material Icons library, which should be optional. You can use CSS to draw the down arrow.
5: Visual design of the components follows Material Design standard as far as I can see - but I have hesitation with how you treat markup in the script.
Now I hope I did not seem all too rude in my feedback - I try to be constructive :-)
Thanks for testing it.
You have duplicated the otions into a lot of divs. In my opinion it's no longer a select element - it's someting else.
Yes, exactly. It is no longer select element - it is component that works on top of select element since each browser has it's own select element styling.
@dgrubelic: I think this is more i line with what you are developing: WAI-ARIA Authoring Practices 1.1, Listbox. If I develop a component myself, I check with this website. Is there a component described here, I get a lot for free with regard to documentation and test cases.
EDIT: ... or the Wai-Aria Combo Box.
And what would be the point here? I actually don't understand you. Are you saying that i'm doing something wrong with this implementation? And if so, why is it wrong?
How would you submit listbox values through form? As far as i can see, all examples i found online are using exactly select element to accomplish this task. The only difference between select element is
unlike standard HTML select elements, may contain images
TBH, I actually no longer find this discussion productive since i'm just getting info that i'm doing something wrong, but not a suggestion how to improve (or totally rewrite) current component state. That being said, I'll remain my focus on current implementation and see what MDL team has to say about my proposal.
I have tried to be constructive in my feedback, but if your perception is different I respect tha.
+1
+1
This is really not constructive comment as we already know how much this component is needed. Actually, i have no idea on which part do you focus with your "+1". Is it topic and component itself, or some comment...
Also, you can subscribe to this topic, if that is why you're commenting...
Guys, I just want to point out that it is very hard to take MDL as a serious choice for material design based UI toolkit if it does not even provide select/dropdownlist component. Using a standard HTML select within an MDL screen makes the UI look inconsistent/ugly.
Hope you will consider prioritising this for next major version. If not a full-fledge select component, at least an interim solution/guidance...maybe adopting/adapting some of the good work from the guys on this issue.
Thanks! If you agree, please 👍 this post to help bump its priority.
I have no idea how this issue can be open for almost a whole year and there is still no solution. Is this still in active development, apart from the external pull requests? The last commit in any branch seems to be over 1 month old. Without a select component, this is really not working out for anybody really.
... and please, no JS generated elements! It'a a pain to style such stuff; a designer shuld have 100% control of markup. Don't make the Java Server Faces mistakes all over again.
There are quite a few issues with modifying the styling here. It is a non-trivial issue and finding the best path forward requires a lot of testing and prototype code to churn though. It takes time and everyone has other tasks to work on as well.
Select inputs are a form component, which is _extremely high priority_ for web sites. However, due to it being a form component that means much more care needs to be taken in modifying/replacing it. Whatever we do needs to be fully accessible and align as closely as we can to the MD spec.
Restyling native elements are notoriously difficult and also near impossible to align to MD with just that. So replacing the elements somehow is required (which means JS generated elements.) However, they must built with accessibility in mind which increases the difficulty. And how we handle this on mobile is also undecided.
On mobile, we can either provide the custom design which isn't very accessible for people with vision impairments. So most likely we would want to fall back to the native select UX on mobile devices, which makes things more difficult to get just right.
This problem is far from trivial and will require quite a few days of work from whomever puts forward this work if they do it before I get to it (which I'm planning on after we finalize how we want 2.x components to look.) But, it needs to be fully accessible and align to MD standards which is problematic, especially when the spec currently isn't built for web/desktop usage.
@GabrielGil. To style a select box, as you mention, is no trivial task - especially if one wishes to preserve the semantics. The simplest is perhaps to give it a light MDL overhaul, so that when it acts as a dropdown list it is consistent with MDL text fields. If anyone wants more advanced list boxes, one can create a component for this, but not based on a select element that has limited styling capabilities.
If we do a simple version that doesn't align we are only going to get repeated complaints that we aren't aligning. :frowning:
There isn't a way to win here except to put forth the full effort initially to completely align (except where we absolutely shouldn't) and be accessible.
@kctang @devboxr If you just need a simple dropdown select element, you can just pull code from my github: https://github.com/leifoolsen/mdl-ext/tree/master/src/selectfield
Live demo: http://leifoolsen.github.io/mdl-ext/demo/selectfield.html
Some alternatives:
https://github.com/MEYVN-digital/mdl-selectfield
https://github.com/CreativeIT/getmdl-select
https://github.com/mebibou/mdl-selectfield
https://github.com/trentsp/mdl-select
Superseded by #4475.
Did anyone implemented an input select using mdl?
Something like this: https://reactcommunity.org/react-autocomplete/async-data/
Is there any codepen available?
Hello all,
I was searching for a component that fulfills all my needs, but I never found that, so I decided to create my own Jquery plugin for this purpose. It has a filter functionality, and supports multiselect, as well as some other minor stuff.
If you still looking for something like this, check it out, and let me know how it worked out for you! :)
Find all here:
https://github.com/qtipet/material-searchselect
Good luck!
I made a great mistake using mdl template , Now i have to start over with using a new material template
Most helpful comment
Guys, I just want to point out that it is very hard to take MDL as a serious choice for material design based UI toolkit if it does not even provide select/dropdownlist component. Using a standard HTML select within an MDL screen makes the UI look inconsistent/ugly.
Hope you will consider prioritising this for next major version. If not a full-fledge select component, at least an interim solution/guidance...maybe adopting/adapting some of the good work from the guys on this issue.
Thanks! If you agree, please 👍 this post to help bump its priority.