[popover] Dialog with popover-like triggers

[una]

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 that popover and popovertoggle 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:

1. A new value for the popover attribute to clarify behavior such as popover=modaldialog
2. A seperate declarative trigger for dialog, such as dialogtarget=foo dialogtargetaction=modal (@mfreed7's suggestion)

[una]

Just saw #736, this might be a duplicate of that

[lukewarlow]

Happy to close my issue in favour of yours :)

[lukewarlow]

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?

[mfreed7]

Some initial thoughts on solutions:

1. A new value for the popover attribute to clarify behavior such as popover=modaldialog
2. 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.

[hidde]

In this case, the popovers should probably be dialogs, but making them , plus invoking them with .showModal() is the only way to get this behavior.

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 whatwg/html#9167, where a more generic openabletarget attribute is proposed.

[lukewarlow]

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.

[una]

I would love if it could be as simple as:

<button popovertarget="my-dialog"> Open Dialog </button>

<dialog id="my-dialog" popover>
  ...
</dialog>

[tbondwilkinson]

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.

[jimmyfrasche]

I'd like:

<button dialogtarget="my-dialog"> Open Dialog </button>

<dialog id="my-dialog" modal>
  ...
</dialog>

[una]

@jimmyfrasche I'm good with that too

[lukewarlow]

whatwg/html#3567

[jpzwarte]

So I'm pasting a code example here from whatwg/html#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.

[css-meeting-bot]

The Open UI Community Group just discussed [popover] Dialog with popover-like triggers.

The full IRC log of that discussion

<gregwhitworth> Topic: [popover] Dialog with popover-like triggers
<gregwhitworth> github: https://github.com//issues/741
<jarhar> una: this isnt a new topic, there are other issues that have been opened in whatwg and openui, how do we have declarative syntax for popover work for dialog
<jarhar> una: popover=hint might work in this case
<jarhar> una: we need clarity, there are perspective on what syntax would work like. not sure if whatwg is better for this discussion, just want to make sure we have thoughts on this
<masonf> q+
<gregwhitworth> +1 on the popover API being solid
<jarhar> una: i really like the syntax for popover and id love to use that for dialog, whether thats attributes or however we decide to have thoughts
<gregwhitworth> q+
<JonathanNeal> solid? why not svelte.. kidding kidding kidding!
<jarhar> una: i dont know if im looking for resolution, but should we discuss this here or in whatwg, and do we have an opinion on what this would look like
<jarhar> masonf: i think it seems like a good place to start talking about it. i could see this moving more to whatwg if its a more general thing thats a bigger thing
<jarhar> masonf: as it related to dialog thats good
<jarhar> masonf: trying to conflate modality and popovers - i dont think that popover=modal is a good thing, thats what dialog elements are for
<jarhar> masonf: id be in favor of a separate set of attributes for dialog which behaves in the same way
<scotto> q+
<gregwhitworth> ack masonf
<jarhar> una: i think theres a bit of overlap. when you use auto popovers you get backdrop, but you dont get the inerting of the rest of the page. i dont know if thats clear to someone that using popover, that theyre that different.
<hdv> q+
<jarhar> una: we need to find a way to make those differences clear, make sure that people arent conflating them and are using each for the right use case
<jarhar> una: its fine if we have unique attributes, different for dialog
<jarhar> una: there are dialogs which are non-modal that woul dhave a different interaction with the ui, whats the difference between those and manual popovers
<JonathanNeal> And I thought popover was just an ephemeral dialog. Oh no, is that a minority opinion? Sorry.
<jarhar> masonf: cleanest is that we deprecate non-modal dialog, dialogs are always modal, always activate them with a single button
<jarhar> una: any cases that youd want to use a non-modal dialog thats different from a popover
<jarhar> masonf: you could put popover on any element, dont have to use dialog
<jarhar> masonf: cant do that with a non-modal dialog because it has to be a dialog element
<jarhar> una: having a way to break out behavior vs semantic meaning feels like an easier solution to each than to use
<jarhar> masonf: youre calling for abolition of all behavior on the dialog element
<jarhar> gregw: i think this is the perfect place to discuss this, super approachable for anyone
<jarhar> gregw: by all means also go in on whatwg issues
<masonf> q?
<jarhar> gregw: to your tactical statement, when we first started it thats what the office team started for - give me attributes to put on my elements, and let the element define semantics
<jarhar> gregw: we could make a toast element
<jarhar> gregw: huge supporter of both deprecating non-modal and in favor of getting rid of all behaviors on dialog and saying it is a semantic thing only and only leverages popover apis since its 90% the same and it is confusing to unas point
<jarhar> gregw: theres 3 or 4 different issues here
<gregwhitworth> ack scotto
<jarhar> scotto: i am supportive of opening modal dialogs without script
<jarhar> scotto: i wonder how to do that in a way that makes sense
<jarhar> scotto: put a modal attribute on the dialog. on the surface that could work but theres some displeaussre in html where attributes can mean something in one context but be irrelevant in others
<jarhar> scotto: if they put modal on the dialog but then force it open via css, if that modal attribute actually made the rest of the page inert, then through some error of css then the entire page is unusable, particularly to people using AT
<gregwhitworth> with regards to declarative opening/closing of dialog I would align with Mason on a dialog specific API definitions, not leveraging popover unless we can get una ambitious option of dialog only being semantic
<JonathanNeal> seems like unopened modals need to exist in the opposite of top-layer. bottom-layer, non-layer, hell-scape, whatever.
<jarhar> scotto: if we could make that attribute only have functionality if someone opened it via showmodal method or triggering element, then thats totally fine, but we have that other situation that HTML wants to get away from is that checked attribute on input type checkbox where its only usable on page load
<jarhar> scotto: after its changed it doesnt mean anything
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack hdv
<jarhar> hdv: i agree with a lot of what was said, i do think its useful to discuss in this venue
<jarhar> hdv: i agree that its a danger to become really complicated
<jarhar> hdv: ive written a blog post about the difference between dialogs and popovers, and its hard
<jarhar> hdv: theres a lot of opportunity to make it easier if we have a way that makes dialogs similar to popover
<jarhar> hdv: declarative ways of openining them and things like that
<jarhar> hdv: careful that we dont introduce more complication, more ways to get it wrong
<jarhar> gregw: do you guys have use counter of dialogs for modal vs non-modal
<jarhar> masonf: yes
<jarhar> gregw: that would be my curiosity, agree that non-modal can be deprecated
<masonf> showmodal: https://chromestatus.com/metrics/feature/timeline/popularity/3726
<masonf> show: https://chromestatus.com/metrics/feature/timeline/popularity/3725
<jarhar> una: my concern with deprecation, we will get questions about what if a i have a dialog experience in a non-modal popover that appears at top of page, that might be semantically a dialog, i dont konw
<jarhar> una: if those cases exist it seems like we would get some pushback
<jarhar> scotto: there is some discussion on the scope of deprecation, we can discuss another time
<jarhar> masonf: showmodal has 30x usage of show, show is just inched above easy to deprecate threshold
<jarhar> gregw: that one to me we can totally have an issue and have a stance
<gregwhitworth> Zakim, end meeting

[keithamus]

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

[mfreed7]

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

That was indeed the proposed direction: deprecate dialog.show() but keep <dialog popover=manual> as the replacement.

[mfreed7]

It looks like the discussion for this feature request is really happening over on whatwg/html#3567. Should we close this issue, to avoid having it in two places?

[nt1m]

FWIW, <dialog popover> + showModal() wouldn't achieve the use-case as desired, as dismissing the popover dialog would leave the content inert.

[brechtDR]

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

[una]

Closing in favor of whatwg/html#3567