Refactor and improve the Dialog utility

[endigo9740]

The store queue we have now fully supports this, we're just not taking advantage of it currently. The idea would be to use a "stack of cards" appearance like so:

Likewise we should investigate moving this component to a native <dialog> element. This now has has support in all major browsers:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

Though we should be careful to balance visual aesthetics and a11y features.

[motopods]

<dialog> requires Safari at least greater than or equal to 15.4，is this requirement a little too strict?

[endigo9740]

Hey Motopods, first off there's no guarantee we'll move forward with this. As noted, we're just going to investigate the technical capabilities. There's plenty of issues that could prevent us from moving forward. But the reason I'm keen to add it is due to the a11y benefits, such as proper focus capture. Things that are very difficult with custom rolled solutions.

The Dialog elements was adding in Safari in 15.4, which came out six months ago: https://webkit.org/blog/12445/new-webkit-features-in-safari-15-4/

Version 16 is now the current version: https://webkit.org/blog/13152/webkit-features-in-safari-16-0/

So 15.4 is a version behind. If this was IE, where corporate users were limited from being able to update, I might be more concerned. However, Mac is primarily a consumer OS. Users do not face the same barrier for updating.

The main thing to keep in mind is Skeleton is a pre-release/beta software. It's not intended for production use YET. That's what v1.0 will signify. By the time it is I think this feature would have had plenty of ramp up time for anyone that is going to update, to have updated.

[endigo9740]

Feature request to prevent dialog from closing until prompt is completed: https://github.com/Brain-Bones/skeleton/issues/385

UPDATE: reviewing with the Skeleton core team we've opted to pass on this feature for now. We feel this could be harmful to UX.

[endigo9740]

Feature request: be able to replace the entire contents of a dialog via component templates

[endigo9740]

Feature request: custom "confirm" button text.

[endigo9740]

Note, all above and current feature requests have been included in the original post at the top of this thread.

[endigo9740]

Made some progress today, but documenting a few outstanding issues I need to work though with the native <dialog> element:

1. Our previous Dialogs handled display via a "if" statement, but we should probably lean into the native open attribute or trigger showModal/show/close() methods
2. Svelte transition animations may only be possible with the "if" statement method. But creating standard CSS transitions work in a <style> element.
3. Tailwind doesn't handle the ::backdrop element styling well. backdrop:bg-black/50 works, but backdrop:bg-surface-500/50 does not.
4. The :backdrop only shows if we trigger the dialog with the showModal() method, show() and the open attribute appear without this in place in all browsers tested.
5. Currently I don't believe the native element will support a visual stacked queue. We may need to opt for a "swap" effect.

I'll pick up on this tomorrow and update with my progress asap.

[endigo9740]

I've spent more time on this but continue to run into issues with the native element. I've copied my Discord message to save some time here:

[endigo9740]

Notable updates for today:

• Component examples for a ListBox and video embed added
• New Focus Trap action created. This is reusable and will be part of the library
• Flushed out the docs for both Focus Trap and the Dialog utility
• Implemented a means to apply class styles per dialog instance via classes
• Began testing how to animate the transition between dialogs

Still some work to be done with the dialog transitions, but I'll pick up here tomorrow!

[endigo9740]

All notable features are now implemented so marking this ready for QA!