feat(SELECT): Allow dropdown to be wider than parent form-field like before v15
Feature Description
Since v15, mat-select dropdown menu width stick strictly to the mat-select itself (cf. https://material.angular.io/guide/mdc-migration#select). But IMO, this is a terrible behavior because it may decrease usability on small devices or, more generally, in any place you need to have a small select (like a select inside a search field, exemple : https://www.amazon.com/). It may force devs to switch to a mat-menu alternative which is not built to work with form controls
Use Case
What was done in previous versions of Angular Material was great and solve issues exposed above
It's worth noting that previously the width was purely a side-effect of the design that required it to fit the selected option on top of the trigger. That being said, we should be able to provide a better way to control the panel's width.
Thanks for the quick answer @crisbeto :)
One more thing, this feature request could be applied to mat-autocomplete too.
This change comes as a result of closer alignment with the material design spec, which shows select drop-downs always matching the width of their triggering form-field. The thinking behind the design appears to be that if your dropdown needs to be bigger, you should make the triggering form-field bigger. This makes sense because if you just adjust the size of your dropdown, it results in a select where the selected value can't easily be read when the dropdown is closed.
Another data point for this is the native <select> element which also ties the dropdown size to the trigger size. The native select has the nice feature of automatically adjusting the width of the trigger to be able to fit the largest item. That is unfortunately tricky to do for the <mat-select> since the options aren't rendered initially and we don't really know how large they are.
I'd be curious if there are example use cases you can provide where increasing the width of the select dropdown but not the trigger is desired.
One simple use case: selected value is a flag icon, items are flag + language in text.
@mmalerba in fact I agree with your way of thinking but it’s very constrictive on mobile environment. The proper alternative is the mat-menu. But it requires more code and cannot be integrated with form controls out of the box.
Here's another example where the new functionality causes issues when space is limited (i.e. mobile). As you can see the result value fits perfectly inside the mat-select but is hidden in the overlay:

@sqljim Would you be able to share a stackblitz reproduction of that? I'm curious what's going on there because it looks like there's 2 dropdown arrows and the dropdown seems narrower than I would expect. I believe it should extend all the way to the edge of the filled box, which would give it the needed space:

@sqljim Would you be able to share a stackblitz reproduction of that? I'm curious what's going on there because it looks like there's 2 dropdown arrows and the dropdown seems narrower than I would expect. I believe it should extend all the way to the edge of the filled box, which would give it the needed space:
No, there's only one select. This field lives inside a div that is limited to 110px wide on mobile. but next to the select is an icon with an 'expand_more' and 'expand_less'.
I hacked around it by removing the 16px of padding on the mat-mdc-option on @media max-width 600px.

@sqljim I've created an example like you describe and the dropdown does extend to the edge of the filled box: https://stackblitz.com/edit/angular-nvgkbf-qpz9um, so I suspect there are some custom styles or something being applied in your version.
@stnor We do have support for custom trigger DOM, so I do consider the flag selector case you mention to be a valid one.
@mmalerba yes you're right. I was wrong saying my select was 110px, it's actually much smaller. In any case, you are right, that it does extend to the end of the select. My issue is still with the padding at the start. But I can easily work around that if that's intended behaviour.
@stnor We do have support for custom trigger DOM, so I do consider the flag selector case you mention to be a valid one.
Thanks. So, is this use-case something you plan on supporting in the future with the select/forms, or are you saying it's supported now? If the latter, pointers would be appreciated. :)
I'm saying its something we should support in the future.
@mmalerba If possible looking for an update on if there will be an api to expose the ability to use minWidth instead of width or if there is a suggestion that can be used as workaround until then.
Anyone found a workaround yet? Ive tried to set .cdk-overlay-pane selector to "width: auto", however this messes up every other dialog. And i cant find a way to increase the specificity, since the overlay-pane is not connected to any class i have.
Anyone found a workaround yet?
@ly000 Same dilemma here so I spent a bit of time on achieving this the best way - we can make use of the has selector and only taget the cdk pane if its child has class mat-mdc-select-panel.
.cdk-overlay-pane:has(.mat-mdc-select-panel) { min-width: fit-content; }
what is the issue to return the dropdown functionality from version 14? it's hard to fathom the idea of who could implement dropdown menus so poorly and simply make it impossible to switch to a new version.
I've edited my comment above, if you use min-width: fit-content this expands the select panel to fit content when content is wider than the containing form-field and also expands the panel full width when the content width is less than the form-field container (to keep the existing behavior) .
Not ideal but it is a simple work-around - I've had to push this to over 20+ apps :/
.cdk-overlay-pane:has(.mat-mdc-select-panel) { min-width: fit-content; }
I've edited my comment above, if you use
min-width: fit-contentthis expands the select panel to fit content when content is wider than the containing form-field and also expands the panel full width when the content width is less than the form-field container (to keep the existing behavior) .Not ideal but it is a simple work-around - I've had to push this to over 20+ apps :/
.cdk-overlay-pane:has(.mat-mdc-select-panel) { min-width: fit-content; }
yep, but it won't help with the correct positioning of the select menu as an example below: https://stackblitz.com/edit/angular-nvgkbf-o5tvc6
@didemchenko the selected item positioning effect was removed from material spec. So the v15 implementation is actually the good one. The only issue here is that imply constraining drop-down width to the container
@didemchenko the selected item positioning effect was removed from material spec. So the v15 implementation is actually the good one. The only issue here is that imply constraining drop-down width to the container
I can rephrase - similar functionality of version 14 is preferred
- The second issue is below
https://stackblitz.com/edit/angular-nvgkbf-o5tvc6
Any workaround?? our customer does not accept the new look, so we can't go to production with the new version.
There will be an input to control the select's dropdown width in version 16.1.
There will be an input to control the select's dropdown width in version 16.1.
+1 additional bug for the select component and new panelWidth property. select list not positioning correctly. example below: https://stackblitz.com/edit/8vtplv-ygzegh?embed=1&file=src%2Fexample%2Fselect-custom-trigger-example.ts
I found an easy solution:
In styles.css add:
.fit-content.mat-mdc-select-panel {
min-width: fit-content;
}
In your component use panelClass="fit-content" attribute:
<mat-select [formControl]="selection" panelClass="fit-content">
<mat-option [value]="null">(Unselect)</mat-option>
<mat-option *ngFor="let option of options" [value]="option">
{{ option }}
</mat-option>
</mat-select>
This ensures the panel has the minimum width of the widest content in the select panel.
This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.