aurelia / aurelia

Aurelia 2, a standards-based, front-end framework designed for high-performing, ambitious applications.
MIT License
1.39k stars 147 forks source link

Dialog should be based on web standards HTML <dialog> element #2053

Open Stopi opened 1 month ago

Stopi commented 1 month ago

πŸ™‹ Feature Request

Simply as in the title: dialog box should be using HTML standard \

element. There was a similar ticket in Aurelia V1: https://github.com/aurelia/dialog/issues/335

πŸ€” Expected Behavior

One feature that would be allowed by the HTML element is having a true modal dialog where it's impossible to interact with what's behind the dialog box.

That would also allow the use of the "autofocus" attribute inside the dialog.

😯 Current Behavior

Currently, there's a complicated way of styling the overlay (which is a DOM element itself). Not sure if anyone wants to create a class for that. Why dealing with a separated DOM element when they just want a popup dialog box. The standard ::backdrop CSS seems like an elegant solution.

Why reinventing the wheel over HTML standards? A \

element already exists in browsers, let's make use of it.

πŸ’ Possible Solution

One problem with the HTML \

element is you can't simply close the dialog by clicking outside of it. There are solutions discussed here: https://stackoverflow.com/questions/50037663/how-to-close-a-native-html-dialog-when-clicking-outside-with-javascript An easy one would be:

myDialog.addEventListener('click', event => {
    if(event.target === myDialog) {
        myDialog.close();
    }
});

πŸ”¦ Context

With the current dialog package, the resulting dialog box isn't really "modal". There is indeed a visual overlay to cover what's behind the dialog, but you can still interact with it. You can reach all background inputs navigating with the [TAB] key.

bigopon commented 1 month ago

Thanks @Stopi , for the true true modal, we need to implement tab focus trap for non native <dialog/> renderer. I was assuming this shouldn't be opinionated, but maybe it should be. The overlay being non-dismissable is already configurable via overlayDismiss. Though generally we probably need to revise the setting APIs if we want it to be more standard aligned.

Currently, there's a complicated way of styling the overlay (which is a DOM element itself).

Styling the overlay is not complicated, it's actually simpler than the pseudo selector ::backdrop since with ::backdrop you'll need accompanying CSS, while with an actual element being the overlay, it can be inline style via .style.... = someCSS. And for CSS, you'll need to know where to add it, since the <dialog/> could be added inside a shadow dom root, which makes it even more complicated.

A

element already exists in browsers, let's make use of it.

agreed πŸ˜ƒ , though there'll need to be some more work ensuring we got the right APIs.

@ekzobrain any thoughts on this?

ghiscoding commented 1 month ago

FYI, <dialog> is not supported in Opera mini, so I guess you would need a fallback

https://caniuse.com/dialog