Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Misplaced Dropdown content when opened from Dialog #450

Closed
devmount opened this issue May 31, 2021 · 6 comments
Closed

Misplaced Dropdown content when opened from Dialog #450

devmount opened this issue May 31, 2021 · 6 comments
Assignees
@claviska
Labels
bug Things that aren't working right in the library.

Comments

@devmount
Copy link
Contributor

Describe the bug
When sl-dropdown is placed into a sl-dialog, the dropdown content is mispositioned. I observed this since 2.0.0-beta.42.

To Reproduce
https://jsfiddle.net/devmount/oz3c6v8k/

Expected behavior
I expect the dropdown content right next to the dropdown field without a large gap in between.

Screenshots
image

Desktop (please complete the following information):

  • OS: Win10
  • Browser Firefox
  • Version 89.0b15 (64-bit)

Additional context
Maybe related to #449
@devmount devmount added the bug Things that aren't working right in the library. label May 31, 2021
@devmount
Copy link
Contributor Author

Addition: I'm experiencing the same bug with the sl-select component.

@claviska
Copy link
Member

The example is using the hoist prop, which uses a fixed positioning strategy. This usually works well, the caveat being when the containing block is not the viewport. From the docs:

The hoist attribute forces the panel to use a fixed positioning strategy, allowing it to break out of the container. In this case, the panel will be positioned relative to its containing block, which is usually the viewport unless an ancestor uses a transform, perspective, or filter. Refer to this page for more details.

Because the dialog uses position: fixed, the containing block is not the viewport, hence the visually incorrect offset. Unfortunately, without physically hoisting the menu to the <body> (which introduces other problems) there's really no good way to solve this.

This is a pain point of HTML/CSS, which is why I started the discussion around the position: popover concept. I'm also pretty excited that there's interest in solving the problem from the HTML side of things as well.

See also: #265 (comment)

Before landing on the current API, I experimented heavily with different hoisting options, including moving things around in the DOM, cloning the panel, creating a separate component for the panel — none of them were clean solutions, nor did they provide an intuitive API for users.

That said, I'm closing this since the behavior is documented and expected. The only way I can think to address this sanely in the future will be with a new CSS property.

As for your example, you should be able to remove the hoist prop and the overflow on the dialog to achieve the result you want. See this comment for details.

I'm experiencing the same bug with the sl-select component.

Select uses dropdown under the hood, so that's expected if you're hoisting.

I'm closing this as a wontfix since this is the documented behavior.

@devmount
Copy link
Contributor Author

devmount commented Jun 1, 2021

Thank you for this detailed answer! Totally missed that in the docs. It just felt like a regression as this was (unexpectedly?) working fine up to 2.0.0-beta.41.

claviska added a commit that referenced this issue Jun 1, 2021
@claviska
fixes #450
9f40568
@claviska
Copy link
Member

claviska commented Jun 1, 2021 •
edited
Loading

It just felt like a regression as this was (unexpectedly?) working fine up to 2.0.0-beta.41.

I didn't realize this worked before. I took another look and realized I missed something the first time around.

Because the dialog uses position: fixed, the containing block is not the viewport, hence the visually incorrect offset.

I was mistaken here...I should have said "because the dialog uses position: fixed and translate. A fixed position alone will ensure the containing block is the viewport.

However, the translate is only used for show/hide animations. As such, they're not necessary to keep on the dialog after it shows. By removing fill: 'both' from the animation, the dialog no longer maintains the transition after showing and the containing block remains the viewport.

TL;DR – this will work as expected again in beta.43.

@devmount
Copy link
Contributor Author

devmount commented Jun 1, 2021

Great news, thanks for looking into this again! 👏🏻 😍

@devmount
Copy link
Contributor Author

devmount commented Jun 4, 2021

I can confirm this is working again in 2.0.0-beta.43. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@claviska claviska

Labels
bug Things that aren't working right in the library.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@claviska @devmount