microsoft
Fast Select Dropdown does not break out of parent component
fast-select with options does not break out and options are hidden. In almost all the practical use cases the select component will be used inside the parent component
To show the issue, i just added a grid control and added fast select inside a grid cell.
<fast-data-grid grid-template-columns="1fr 1fr 1fr">
<fast-data-grid-row>
<fast-data-grid-cell grid-column="1">
Name
</fast-data-grid-cell>
<fast-data-grid-cell grid-column="2">
<fast-select>
<fast-option value="1" style="z-index:1">Option 1</fast-option>
<fast-option value="2">Option 2</fast-option>
<fast-option value="3">Option 3</fast-option>
</fast-select>
</fast-data-grid-cell>
<fast-data-grid-cell grid-column="3">
Info
</fast-data-grid-cell>
</fast-data-grid-row>
</fast-data-grid>
Expected Behavior: The Fast Select dropdown should break out of parent control and not hidden by default.
@scomea may not chime in right away as he's taking some time off this week. I'll do my best to articulate some of the problem and our long term solution. I think the overall problem is the same one explained a bit as part of this comment. One thing that may be contributing to this behavior in the WC select as well is that I don't believe it's making use of anchored-region.
There are two explainers that could each independently help solve this problem for us in the long term:
- Popup - This will help formalize the expected behavior via a new HTML element (
<popup>). - Improving the customization of form controls, specifically
<select>- Once available we'll likely use a progressive-enhancement model to use this control when available.
In the short term, I think it'll be important to get @radium-v's thoughts here on whether using Anchored Region is a good short term fix, and what the potential implications are of doing that. Alternatively, I think some of this is due to CSS, most often with positioning, which often means a very tightly coupled relationship between parent/child. This makes it difficult for us to come up with a universal, "it just works" approach for every element. The two long term solutions will help solve that for good I believe. In the meantime, I think the question becomes, "What's the right short term solution and how much coverage can we get?"
Yes, anchored region should be able to give us some options here. I've been meaning to start a branch to test that out.
@chrisdholt, I expect the fact that the fast-combobox dropdown menu is cut off when it is used as the column template for a fast-datagrid has the same root issue you're describing (making sure I shouldn't file a separate issue). If it is the same issue, as I expect it is, can you elaborate on how you would use the anchored-region to solve the problem in the short term?
Anchored-region is able to position itself relative to its anchor in either a "fixed" or "absolute" positioning mode. Fixed positioning is useful precisely because it allows the flyout to break out of parent containers more easily.
~~I think I should have been a bit more specific in my ask. So if I, as a current user of the FAST components (in particular the FluentUI/Blazor widget set), want to be able to have the fast-combobox (i.e. FluentComboBox) have its dropdown menu break out of its owner's bounds, is there a way for me to use the FluentAnchoredRegion to do so? I wouldn't expect that there is, as the div that is responsible for this~~ ~~(the popup)~~ ~~is tucked away in the template of the fast-combobox.~~
~~I feel I may be missing something, and I apologize if I'm being obtuse.~~
Edit: I think I may have been misinterpreting @chrisdholt's suggestion, in that I believe he means that as a "short-term" solution the actual FAST implementation of the various widgets that use dropdowns could leverage the anchored-region to break the dropdown menu div outside of its owners bounds, but that there are implementation difficulties with this stemming from positioning, as well as tight coupling concerns.
My current read on this is, as a consumer of FAST (or the FluentUI/Blazor-based widgets), that there is nothing I can do to resolve this at the moment.
My current read on this is, as a consumer of FAST (or the FluentUI/Blazor-based widgets), that there is nothing I can do to resolve this at the moment.
I wouldn't say "nothing", just not some easy out of the box solution using select as it is currently. You'd need to 'roll your own' to some extent.
We are tracking this work on Select, it’s simply behind some accessibility work that’s currently in process.
Would you expect to do the same work on the Combobox at the same time?
Would you expect to do the same work on the Combobox at the same time?
Yes, these are closely aligned and we’d expect to do both simultaneously. Hopefully it’s not too far off.
I had a few attempts at this without it being major changes, but I think it's best if scomea or someone else took a look at it!
@chrisdholt , Any update on the timeline for a fix ? Almost an year since the original issues was opened! This does impact a lot of basic use cases for simple selections.
The FluentUI fast wrappers for Blazor also has the same issue.
@chrisdholt , Any update on the timeline for a fix ? Almost an year since the original issues was opened! This does impact a lot of basic use cases for simple selections.
The FluentUI fast wrappers for Blazor also has the same issue.
Also very interested in a fix. In the case of our application, the dropdown sits on a card that can be one of many cards in the view. One would expect the dropdown to just open over the top of the other elements on the page, including its parent element. As it stands, this is effectively preventing us from using the select dropdown.
I have a prototype branch that hooks up select to a refactored anchored-region positioning class here -https://github.com/microsoft/fast/tree/users/scomea/anchor-region-refactor
That would be able to escape parent containers much more effectively.
@chrisdholt , Any update on the timeline for a fix ? Almost an year since the original issues was opened! This does impact a lot of basic use cases for simple selections. The FluentUI fast wrappers for Blazor also has the same issue.
Also very interested in a fix. In the case of our application, the dropdown sits on a card that can be one of many cards in the view. One would expect the dropdown to just open over the top of the other elements on the page, including its parent element. As it stands, this is effectively preventing us from using the select dropdown.
@scomea has done some explorations here and I posted in our discord today that @radium-v has been iterating on adding this to select/combobox and likely will have something up in the next day or so. Landing the desired path here for our Foundation approach is a key part of our current alpha state of Foundation. Whatever is the default approach, we plan to enable users to take control or opt-out of the behavior if need be as well. The ultimately goal is a good default with the flexibility to customize for unique scenarios.
Hey guys, just wondering if there was any progress on this ?
It's fixed in the latest beta - unfortunately I see this is breaking so it's unlikely to be included in the current stable release.
Unfortunately @microsoft/fast-components has been deprecated for some time and @microsoft/fast-foundation is in progress to be deprecated per #6955. If this issue needs to be address in Fluent UI for those components, please file it there.
