Closed una closed 1 year ago
Just saw #736, this might be a duplicate of that
Happy to close my issue in favour of yours :)
Text from my issue:
This may end up being superseded by a more generic thing such as #700
But I think the modality aspect warrants this being a separate issue.
Currently (well soon) non-modal Dialogs can be shown by using popover attribute.
However, there's currently no way to load a modal dialog without using JS. This feels like a relatively simple but useful addition to the web.
As a rough idea we could add a new modal
attribute to the dialog element and then have a new modaltarget
attribute on the button to match how popover works?
This is perhaps odd considering we now have popover which almost does the exact same thing?
Some initial thoughts on solutions:
- A new value for the popover attribute to clarify behavior such as
popover=modaldialog
- A seperate declarative trigger for dialog, such as
dialogtarget=foo dialogtargetaction=modal
(@mfreed7's suggestion)
I’m biased but I like option 2. I’m worried that popover=modaldialog
is confusing for developers. If you’re building a dialog (and you are, in your example) then I think you should use a <dialog>
. But let’s bring as much learning and functionality as we can from popover. I think that’s option 2. Separate attributes, because it’s not a popover. But functionally very similar.
In this case, the popovers should probably be dialogs, but making them
Agreed, I would advise building these with <dialog>
+.showModal()
, but see the want to have something declarative here too.
I am not big on suggestion (1) (a new value for popover that adds modal behaviour), I feel it would make it harder to teach developers the difference between <dialog>
and popover
(currently, modality seems to be a major differantiator; adding a way to do modal popvers would make the differences even more subtle).
I like suggestion (2), to be it seems like a no-brainer! There is a related discussion over at https://github.com/whatwg/html/issues/9167, where a more generic openabletarget
attribute is proposed.
Could we declare the modality on the dialog itself rather than on the toggle? This fits the pattern of popovers better where the type of popover is declared in the popover attribute. Potentially dialog="modal"? Not sure if this is web compatible though.
I would love if it could be as simple as:
<button popovertarget="my-dialog"> Open Dialog </button>
<dialog id="my-dialog" popover>
...
</dialog>
I also had a discussion about this on #581. The feedback I got at the time was that popover was not intended to support dialog-like modals. I do think people will consistently reach for popover over dialog for modals, because of the new functionality.
I'd like:
<button dialogtarget="my-dialog"> Open Dialog </button>
<dialog id="my-dialog" modal>
...
</dialog>
@jimmyfrasche I'm good with that too
So I'm pasting a code example here from https://github.com/whatwg/html/issues/3567 for clarity:
<button dialogtarget="dialog" popovertarget="tooltip">Click</button>
<div id="tooltip" popover="hint" class="tooltip">I appear on hover</div>
<dialog id="dialog" modal>
<h1>I am modal</h1>
</dialog>
Don't you want to be able to use both popover and dialog with a single button? I know popover="hint"
is not in the current spec, but as I understand it, it was delayed/paused, not rejected.
The Open UI Community Group just discussed [popover] Dialog with popover-like triggers
.
I wasn't at the meeting but it seems like there was discussion around deprecation of non-modal <dialog>
and I'd like to add that there are many instances where one would need an element with a role=dialog
that is also a popover. In that regard I just want to make sure that we're talking about deprecating .show()
on <dialog>
and not deprecating the possibility of <dialog popover>
.
I wasn't at the meeting but it seems like there was discussion around deprecation of non-modal
<dialog>
and I'd like to add that there are many instances where one would need an element with arole=dialog
that is also a popover. In that regard I just want to make sure that we're talking about deprecating.show()
on<dialog>
and not deprecating the possibility of<dialog popover>
.
That was indeed the proposed direction: deprecate dialog.show()
but keep <dialog popover=manual>
as the replacement.
It looks like the discussion for this feature request is really happening over on https://github.com/whatwg/html/issues/3567. Should we close this issue, to avoid having it in two places?
FWIW, <dialog popover>
+ showModal()
wouldn't achieve the use-case as desired, as dismissing the popover dialog would leave the content inert.
@mfreed7 @una I think we can close it :) good to see so many thumbs up on the other issue, that should give it some weight. Seems like a lot of people found their way over there.
Closing in favor of https://github.com/whatwg/html/issues/3567
When playing with
popover
recently, I ran into a scenario which I think will be relatively common: folks wanting dialog-like behavior (i.e. inerting content on the rest of the page when the dialog is open), with the developer ergonomics thatpopover
andpopovertoggle
provide.In this example, I wouldn't want the rest of the page to be interactive while one of the popovers is open (you can see that I can still hover and click on buttons behind the popover
::backdrop
. Not ideal.In this case, the popovers should probably be dialogs, but making them
<dialog>
, plus invoking them with.showModal()
is the only way to get this behavior. Is there a way to get declarative popover-like developer ergonomics with dialog element semantics and behavior?Some initial thoughts on solutions:
popover=modaldialog
dialogtarget=foo dialogtargetaction=modal
(@mfreed7's suggestion)