-
-
Notifications
You must be signed in to change notification settings - Fork 314
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
NEXT: Overlay System (modals/drawers/toasts) #2357
Comments
Please consider including a means to disable the backdrop's click to close feature. The ARIA APG guidelines do allow for this, marking a dialog modal only when both:
|
Please move Modals away from the singleton pattern. |
Here's a proposal for implementing modals/drawers/popups/whatever: REPL While this does still use a "singleton" state under the hood, I'm sure this can be avoided. The idea is that, with snippets, it becomes extremely easy to just pass a snippet to a "openModal" function and it gets rendered. No modal store, no anything. This could then easily be refactored into a |
Thank you @rChaoz - this is somewhat similar to what I have in mind as well (namely how the state rune is used). I've been quietly working on a mixture of Popups and Modals this week, so I should have more to show for this per next week's regular update. Keep an eye out here or in our Discord The general idea is we're going to aim for the following:
But again, I'll plan to showcase my prototypes in next week's update. |
We've provided a more in-depth exploration of our proposal for Skeleton v3 popover and modals here:
We encourage feedback about the proposal be confined to the post linked above. |
Where did we land on not using the registry and just allowing users to simply use the components directly? |
I'll likely add a guide for integrating the native Note that we're using this approach as a temporary solution for our v3 doc search until we get a chance to integrate Floating UI. It should give you a good idea of what's possible: Source (NOTE: this is intermixed with a lot of PageFind search code): I might also encourage you to review the Popover API. It's now (finally) supported across all browsers after a recent Firefox rollout. Personally I find it more intuitive and friendlier than the Dialog: |
So Skeleton will default to the registry? If so, sad to hear. |
Something to consider is the push on progressive enhancement in the SvelteKit ecosystem (e.g., superforms, so it would be great if we could have a JS-less version for server-side rendering the modals and overlays. While popover API is nice, it is still only at 85% availability as of today. If we could get first-class support for dialog elements via tailwind utility classes than it would definitely further the progressive enhancement of Skeleton. However, totally understand that everyone is deep underway in this work. |
@jhechtf sorry for the late reply, but the registry system will be the right approach for a "system". Remember the goal is a universal queue globally scoped throughout your app. If you're just aiming for a quick one-off, the native @TweedChristian you've touched on a few topics here, so let me break this down...
Thanks for your feedback though! And obviously keep an eye out for more updates in the future. |
@endigo9740 I greatly disagree with your decision and am immensely disappointed. I hope we will still be able to make our own modals that fit within the Skeleton system as we are now as your previous system did not work for me. |
Warning
This issue is a work in progress.
This will act as a hub to centralize for this information.
Proposal
Maintainer Requests
The following requests are coming straight from the Skeleton team. These are highly likely be implemented:
Community Requests
The following requests have come from the community and are under consideration:
Enter
key pressed #1757<dialog>
element #2409Bugs and Issues
Feedback
If you have additional updates or requests for this feature, please do so in the comments section below.
The text was updated successfully, but these errors were encountered: