Change menu origin automatically when there is not enough space about skeleton HOT 13 CLOSED

Great suggestion and definitely something on my radar! I was planning a default origin: 'auto' prop setting, that would take into account the edges of the canvas. That way if your menu target place near a corner, it doesn't open off screen.

Thanks for linking the Chakra example as well. If you know of other examples feel free to link them here. I'd like to follow best practices when implementing something like this.

from skeleton.

No problem! Unfortunately ShareX looks to be Windows only (I'm on a Mac!). I'll see if I can track down something similar. In the meantime I've used a free online tool to convert a quick video. Not the best quality, but hey it works!

This only demonstrates vertical scroll, but horizontal should work as well. Likewise the window resize mention in my prior message!

from skeleton.

@pikhosh I've got an initial version of this working on the attached feature branch. Currently it supports the following:

• Default origin is now set to 'auto', which causes the menu to do it's best to stay on screen
• If auto, the menu position is auto-updated on window resize
• If auto, the menu position is auto-updated when the parent element is scrolled

Per that last bullet, it occurred to me that not every app will scroll the body element. Some apps (including the Skeleton docs) have a layout scroll a child element instead (<main> in our case). So to handle this, I traverse up the DOM until I locate the first scrollable parent. Then listen to scroll events on that parent.

This does come with a "gotcha" that if the menu is embedded within multiple scrollable elements it may not act accordingly. However, I'm not sure that's a use case we want to cover right away. It may add a lot of unnecessary complexity.

Also, I'd love to grab a screen recording as a gif, as you did the original post. Would you mind sharing what tool you use to capture this please? I'll follow up with the result asap.

from skeleton.

@pikhosh Feel free to give it a go. I'll aim to merge on Monday. Release TBD.

from skeleton.

@pikhosh Feel free to give it a go. I'll aim to merge on Monday. Release TBD.

It works well! I just wanted to ask how the default origin is selected? Because sometimes by setting auto, the origin switches between tr and br and sometimes tl and bl.

For example, after setting the Select menu origin to auto:

And after removing the disabled menu:

from skeleton.

FYI I'm trying to get us on a schedule to release new updates on Mondays going forward. I feel like what we have is a big improvement over what we had prior, so I'm going to go ahead and include current progress on this in a release today. I do welcome additional feedback on the items mentioned above though. If need be we can address anything else in subsequent updates.

We're going to have an influx of new eyeballs to the library soon, so I want to ensure things are in the best state possible by then. Feel free to follow up either here or on Discord (since I believe both of you are present there)

from skeleton.

@pikhosh I've got an initial version of this working on the attached feature branch. Currently it supports the following:

• Default origin is now set to 'auto', which causes the menu to do it's best to stay on screen
• If auto, the menu position is auto-updated on window resize
• If auto, the menu position is auto-updated when the parent element is scrolled

Per that last bullet, it occurred to me that not every app will scroll the body element. Some apps (including the Skeleton docs) have a layout scroll a child element instead (<main> in our case). So to handle this, I traverse up the DOM until I locate the first scrollable parent. Then listen to scroll events on that parent.

This does come with a "gotcha" that if the menu is embedded within multiple scrollable elements it may not act accordingly. However, I'm not sure that's a use case we want to cover right away. It may add a lot of unnecessary complexity.

Also, I'd love to grab a screen recording as a gif, as you did the original post. Would you mind sharing what tool you use to capture this please? I'll follow up with the result asap.

Thank you for your efforts! I'm happy to see that the project is progressing! 😄
I use ShareX; It's also open source!

from skeleton.

@thomasbjespersen This is ready to be tested. I'd recommend testing under the following scenarios. Make sure you use either the default origin (nix the prop) or specify origin="auto".

1. Place the menu in each of the four corners of the page. Ensure the menu attempts to open towards the center of the page. You can use a wrapping element + Tailwind to do this as follows:

<div class="absolute top-4 left-4">(the-menu-here)</div>

2. Test that the menu updates when scrolling up/down and left/right. It should flip when it passes the horizontal and vertical medians (read: halfway points)

Also please note my comment above that describes the gotcha when embedding the Menu within multiple levels of scrollable elements. This scenario is expected to fail.

Ping me if you need help with any of this!

from skeleton.

This is open to anyone able to test before a final merge.

from skeleton.

@endigo9740 - In the second screen that @pikhosh uploaded, it does seem to not update the origin until the page is scrolled. This is handled by setAutoOrigin I assume.

from skeleton.

@endigo9740 - There also seems to be some minor issues with spacing between the menu and the origin in some instances. Placing the current doc menu in upper left results in spacing differing between different origins. The same when scrolling up and down.

[

](url)

from skeleton.

@pikhosh thank you for testing. Per your question, we have to have some kind of origin set when the page loads, so I'm running the same logic that determines updates the origin on init. Here's a quick visualization of how it works:

Imaging the screen split into four quadrants with the red line being the midpoint. The green blocks (buttons) represent the menu targets. Depending on which quadrant the target is in when the page loads (or post-scroll) the menu tries to open towards the middle.

This updates horizontally and vertically independently. So you have a target/menu low on the page, the menu might open upwards, but when you scroll and pass the midpoint of the screen, then it would flip downward since more space would be available.

Of course you can also override the auto-behavior and specify an origin. The menu will then be hardcoded to always use this, in cases the best origin can be predicted.

This is the best manner I could think of to handle this, however, I'm open to suggestions if you can think of something better.

from skeleton.

@thomasbjespersen note that Pik's screen grabs appear to only show a portion of the screen, not the entire screen size. So it may be be behaving properly if you take into account that there's more screen around what's visible.

Also, while the space between target and menu is a definitely off, the changes I made could not have affected that. I'm using the exact same set of CSS conditions as before. Just added logic to switch between them. That's out of scope of this ticket, so let's file a new one to address that please.

from skeleton.