NEXT: Overlay System (modals/drawers/toasts)

[endigo9740]

This will act as a hub to centralize for this information.

Proposal

• Skeleton Next - Update 8 - Popovers and Modals #2629

Maintainer Requests

The following requests are coming straight from the Skeleton team. These are highly likely be implemented:

• Replaces both NEXT: Drawers #2397 and NEXT: Toasts #2398
• Provide more documentation security restrictions for global reactive state.
• Consider consolidating on the "Registry" method rather than the "Direct" or canned options.
• Provide more parity between params and component props for custom components
• Async/await functionality for response function execution so the Modal stays open while the response computes.
• Review using the native Popover API
• Review using the native Dialog element (likely as a fallback)
• We need to provide more guidance around form handling within modals

Community Requests

The following requests have come from the community and are under consideration:

• Use "inert" for Modal and Drawer to keep focus contained #1655
• Stack based Modal Navigation #1034
• Code completion in ModalComponent #1813
• Modal should return the focus to the triggering element after close #1865
• Confirm Modal should submit on Enter key pressed #1757
• use Skeleton Modals with Shallow routing #2328 (reply in thread)
• Styling issues with native <dialog> element #2409
• feat: optionally prioritize new toasts #2673
• feat: add generic parameters to Modal interfaces #2644

Bugs and Issues

• https://www.youtube.com/watch?v=yZT9906ZCLU

• Modal rendering inconsistent. Disappearing Modals. #2518
• Firefox: Modal with a single button can't be tabbed in #1591
• Custom modal was created with unknown prop "parent" #2176

Resources:

• Native <dialog> element:
  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
  • https://dev.to/thomasvanholder/create-a-modal-with-the-html-dialog-element-tailwind-and-stimulus-573b
  • https://kentondejong.medium.com/we-can-finally-transition-display-none-cbb03831351f
  • https://frontendmasters.com/blog/animating-dialog/

Feedback

If you have additional updates or requests for this feature, please do so in the comments section below.

[adamdva]

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:

1. Application code prevents all users from interacting in any way with content outside of it.
2. Visual styling obscures the content outside of it.

[jhechtf]

Please move Modals away from the singleton pattern.

[rChaoz]

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 <Dialog open={true/false}> ... </Dialog> for ease of use.

[endigo9740]

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 #announcements channel for that.

The general idea is we're going to aim for the following:

• Still provide a queue-based singleton approach. This will default to the registry approach only, while being optional and opt-in.
• We'll also provide styles for the native <dialog> component, or a guidance around styling this yourself, for folks that want modals to be triggers as one-off instances.
• Finally, we're investigating the use of Floating UI to handle the overlay display of not just popover elements (menus, tooltips, etc) but also modals/drawers/alerts. Kind of unifying all of these under a single umbrella.

But again, I'll plan to showcase my prototypes in next week's update.

[endigo9740]

We've provided a more in-depth exploration of our proposal for Skeleton v3 popover and modals here:

• Written Post: Skeleton Next - Update 8 - Popovers and Modals #2629
• Video Walkthrough: https://youtu.be/AU0Lrs16siA

We encourage feedback about the proposal be confined to the post linked above.

[jhechtf]

Where did we land on not using the registry and just allowing users to simply use the components directly?

[endigo9740]

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 <dialog> component as an alternative for that pattern. Then you, as the user, have full control over the state and display locally. It won't be as robust, but it's really the only logical alternative as we're going all-in on the registry for our singleton-based system.

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:
https://skeleton-next-5m3jo1af5-skeleton-labs.vercel.app/

Source (NOTE: this is intermixed with a lot of PageFind search code):
https://github.com/skeletonlabs/skeleton/blob/6aa8868e04102f13a936c6c96d2e8981f87c421f/sites/next.skeleton.dev/src/components/docs/Search.svelte

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:
https://developer.mozilla.org/en-US/docs/Web/API/Popover_API

[jhechtf]

So Skeleton will default to the registry? If so, sad to hear.

[TweedChristian]

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.

[endigo9740]

@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 <dialog> and upcoming Popover API already solve those situations really well. I know a lot of folks were turned off by the complexity in v2, but that'll be highly stripped away in this future iteration. Give us a chance to cook ;)

@TweedChristian you've touched on a few topics here, so let me break this down...

1. There's been a lot of confusion around form submission within modals since the earliest days of Skeleton. In that time we've seen Load functions and Form Actions come to be available in SvelteKit, which have greatly improved the DX for most use cases. But really good modals are inherently portable - which disconnects them from the co-located load functions per load/page section. Really the best approach for this for the forms to submit to internal SvelteKit API routes (aka endpoints). That way they can submit from any portion of the app. As such we do hope to cover this in this next iteration. And btw Superform (while very cool) is mostly additional tooling on top of these underlying tools.
2. We're well aware of the status of the Popover API and CSS Anchoring APIs, which is why @Hugos68 and I have been quietly working on Floating UI Svelte - a full fledge Svelte 5 port of Floating UI React. We feel this will help bridge the gap until the native APIs catch up. And of course we'll have an integration guide for Skeleton v3 asap.
3. Finally, in regards to the native <dialog> component. We have no qualms with folks using that as I mentioned to Jim above. We'll likely provide some additional guidance for that. But I'm not fully convince it's a drop-in solution for our overlay SYSTEM - remember again we're building a systemic solution here. We need to do things like queue modals, which the native element doesn't excel at IMO. But if we can find a way to make it work we will, because Skeleton leans into native-first by default.

Thanks for your feedback though! And obviously keep an eye out for more updates in the future.

[jhechtf]

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

[endigo9740]

Quick update here - I'm in the process of researching modal options for Skeleton v3 and wanted to share that even fi we go all in on the "queue system", the browser native <dialog> element pairs just fine with Skeleton styles. Here's a quick example I worked up within a Astro component (which is fairly close to native html/css/js)

Kapture.2024-10-09.at.15.49.07.mp4

Here's the code used to test:

<div class="w-full">
	<!-- Dialog -->
	<dialog
		data-modal
		class="modal rounded-container bg-surface-100-900 text-inherit max-w-[640px] p-4 space-y-4 z-10 backdrop:bg-surface-50/75 dark:backdrop:bg-surface-950/75"
	>
		<h2 class="h3">Example</h2>
		<p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
		<form method="dialog" class="flex justify-end">
			<button type="button" class="btn preset-tonal" data-modal-close>Close</button>
		</form>
	</dialog>
	<!-- Interface -->
	<div class="flex justify-center items-center">
		<!-- Trigger -->
		<button class="btn preset-filled" data-modal-show>Open Modal</button>
	</div>
</div>

<script is:inline>
	// DOM Elements
	const elemModal = document.querySelector('[data-modal]');
	const elemTrigger = document.querySelector('[data-modal-show]');
	const elemClose = document.querySelector('[data-modal-close]');
	// Listeners
	elemTrigger.addEventListener('click', () => elemModal.showModal());
	elemClose.addEventListener('click', () => elemModal.close());
</script>

<style>
	.modal,
	.modal::backdrop {
		--anim-duration: 250ms;
		transition:
			display var(--anim-duration) allow-discrete,
			overlay var(--anim-duration) allow-discrete,
			opacity var(--anim-duration);
		opacity: 0;
	}
	/* Animate In */
	.modal[open],
	.modal[open]::backdrop {
		opacity: 1;
	}
	/* Animate Out */
	@starting-style {
		.modal[open],
		.modal[open]::backdrop {
			opacity: 0;
		}
	}
</style>

Note that there's various ways to approach defining the DOM references and for handling the animations. In a more flushed out example I'd probably use transition-behavior as I expect it'll have the best cross-browser support long term. This would serve as a progress enhancement, meaning it only displays animations when the browser support the feature.

But everything here is using a mix of Skeleton v3 primitive styles + Tailwind-specific variants such as backdrop:. You can honestly do quite a lot with this!

I'll continue testing this over the next couple weeks though and when we settle on our solution I'll share more in public announcements.

[entrenadorhispano]

Please, consider getting away from singleton patterns.

They seems cool but are very painful to use, also Svelte kit shallow routing is very important on android mobile devices and is difficult to manage on singleton patterns.

Also, focus trap on skeleton 2 is making some components to render user-agent outline which is a very bad orange color in some cases, absolutely odd to the rest of the UI system. (I know is an ARIA standard... but it should be optional)

Thanks for all your time and effort, Skeleton is VERY good and simple to use in general 💯

[endigo9740]

I'll be posting a new Discussions announcement tomorrow that details our solutions for Modals in v3. Anyone wishing to move away from the Singleton-based approach should be please with the new offering! Please also refer to this PR and the new Popover Integrations section within the v3 docs.

Additionally, please refer to this post regarding Toasts, which will be split off to a new dedicated component. Full details can be found in the linked post.

Finally, note that work on Floating UI Svelte will continue beyond the Skeleton v3 launch. Progress for that should be tracked on GitHub.