-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support positioning mat-select panel under the trigger #14105
Comments
It does work. You can see the difference in your example if you remove it, select the second option in the select and open it again. |
ah.... I didn't notice (or expect) that behavior. That's not quite the same as what I was looking to do, then, since the top choice overlaps the input field, which isn't the way that Exposed Dropdown Menu is spec'd. Is there an appropriate way to implement the Exposed Dropdown Menu from the Material Design spec? |
It looks like the "exposed dropdown" is a new addition to the spec. @crisbeto we should think about adding an API to support that. It might make sense to deprecate |
@jelbourn I know that the functionality is a bit like a select, but wouldn't it be nicer to add it to the menu component or even ship it as a standalone component, since there are one or two differences, e.g. the style? This would also help people who read or follow the Material Design Guidelines and then look for the corresponding component in the Angular Material library. In addition, the exposed dropdown menu also contains also things like a "user input" mode or a "inside a toolbar" mode (...I'm not even sure if you can/should use it outside of such a "toolbar"...), see the "Behaviour" section in the MDG. https://material.io/design/components/menus.html#exposed-dropdown-menu |
@TheCom3di4n In my case, I was looking for the select functionality in the Material Design Guidelines, originally starting from "Text fields" and found it under menu, so I'd actually prefer that the Material Design Guideline folks consider at least providing a cross-link in the other direction. |
@takamori I fully agree with you, I also think that this is more of a select, as I already wrote above, and would feel more comfortable if they would place this component under the select in the Material Design Guidelines, since its behavior rather describes a kind of the native HTML select (...exactly one option can be selected...). By the way, I find it really unfortunate, for reasons like these, that there is no issue tracker or public forum for the Material Design Guidelines in which you can ask questions or even start and have such discussions. But I guess that's intentional. |
The workaround for getting the exposed dropdown might just be adding margin in the panelClass. here's the example: https://stackblitz.com/edit/angular-khatke-8xhpbc?file=styles.css |
@tahaabu that visually looks correct, but once the dropdown is activated, you can't click on the menu to close the dropdown– it looks like there's a |
@tahaabu We have faced with the same issue as @kwong-yw . Fixed(not the final version): HTML: I think you can close the dropdown on document click as well. |
The real way to fix this, without hacks, is to use the https://material.angular.io/cdk/overlay/api I do this
|
@akmjenkins Good point, but this option is already deprecated. It becomes private in version 10. |
Workaround which unfortunately require some code. Also you should properly handle disabled selects. |
Is there any alternative for solving this problem because I have a use case where the option should stick to the bottom or the top? |
I think that the underlying issue here is that everything happens in the overlay-pane element but it isn't accessible through the components that use it. For example, the mat-select has a Maybe it makes sense to not only allow a "scope" to be added to the specific DOM panel elements of these components, but also the overlay-pane in which it resides. This is even easier to accomplish since there already exists such an Input in the overlay-directive : I don't know if this goes against some internal architectural guidelines for components in general at Google, but if it is acceptable, maybe all components that make use of the overlay-directive could benefit from exposing the |
Ended up using an approach similar to @isbor but with the twist of providing a custom implementation of the Overlay in the component's viewProviders. The new class extends the Overlay but adds logic to add a custom class in order to scope the overlay. The benefit to this is the classes are already set when the overlay renders, removing any kind of "temporary invalid states" that might be caused when attempting to manipulate the classes after the component renders. See the example here: |
interesting post. Could you help me to solve my current problem with select-panel position. the expected behaviour is: options cdk-overlay should display on top / below of the dropdown based on the space availability in the screen. |
ngAfterViewInit() { this code snippet solves the above problem, we can change the positions my modifying the above option in the array. |
On angular 11 and above, you can set the select overlay panel class via provider:
Example: Stackblitz |
Bug, feature request, or proposal:
disableOptionCentering as discussed on https://material.angular.io/components/select/api does not appear to have any effect and prevents implementing the "Exposed Dropdown Menu" mentioned at https://material.io/design/components/menus.html#exposed-dropdown-menu .
What is the expected behavior?
Setting disableOptionCentering to true would change the options to appear either below or above the mat-select field.
What is the current behavior?
The options appear over the field, whether or not disableOptionCentering is used.
What are the steps to reproduce?
https://stackblitz.com/edit/angular-khatke
I've tried using
<mat-select placeholder="Favorite food" [disableOptionCentering]="true">
What is the use-case or motivation for changing an existing behavior?
This prevents the ability to implement the Exposed Dropdown Menu.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Repro's at least while using Angular/Material npm 7.0.3 on Chrome 70.0.3538.77 on Mac.
Is there anything else we should know?
The text was updated successfully, but these errors were encountered: