Giter Club home page Giter Club logo

Comments (13)

endigo9740 avatar endigo9740 commented on July 30, 2024 2

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.

endigo9740 avatar endigo9740 commented on July 30, 2024 2

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!

auto-menu

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

from skeleton.

endigo9740 avatar endigo9740 commented on July 30, 2024 1

@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.

endigo9740 avatar endigo9740 commented on July 30, 2024 1

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

from skeleton.

pikhosh avatar pikhosh commented on July 30, 2024 1

@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:
ShareX_mTCo2vgVHQ
And after removing the disabled menu:
chrome_39PCNSpeCv

from skeleton.

endigo9740 avatar endigo9740 commented on July 30, 2024 1

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 avatar pikhosh commented on July 30, 2024

@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.

endigo9740 avatar endigo9740 commented on July 30, 2024

@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>
  1. 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.

thomasbjespersen avatar thomasbjespersen commented on July 30, 2024

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

from skeleton.

thomasbjespersen avatar thomasbjespersen commented on July 30, 2024

@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.

thomasbjespersen avatar thomasbjespersen commented on July 30, 2024

@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.

[

Screen.Recording.2022-08-06.at.9.02.13.PM.mov
Screen.Recording.2022-08-06.at.9.06.46.PM.mov

](url)

from skeleton.

endigo9740 avatar endigo9740 commented on July 30, 2024

@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:

Screen Shot 2022-08-08 at 10 58 30 AM

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.

endigo9740 avatar endigo9740 commented on July 30, 2024

@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.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.