Should popovertarget be generic?

[jakearchibald]

#3567 requests a way to open <dialog> without JavaScript, which seems reasonable.

<button popovertarget="foo">Toggle popover</button>

The above will toggle a popover with ID "foo".

Should we rename popovertarget to openabletarget (or whatever), and allow it to work with other things that can be open/closed, such as <dialog> and <details>?

[jakearchibald]

I guess a tricky part is, with <dialog>, does it open modal or not?

[nt1m]

There was some discussion around deprecating dialog.show() in favor of <dialog popover> which would address this issue.

Regarding modal vs. non-modal, I think letting HTML open modal dialogs without JS is a bit too much power given they render the whole page inert.

[hidde]

There was some discussion around deprecating dialog.show() in favor of which would address this issue.

I would think it makes things easier for developers to distinguish between (and correctly use) dialogs and popovers if <dialog> would always be modal and popover always be non-modal.

Should we rename popovertarget to openabletarget (or whatever), and allow it to work with other things that can be open/closed, such as <dialog> and <details>?

I think this makes sense (including popovertargetaction ➡️ openabletargetaction, or something more bikeshedded).

[nt1m]

dialog.showPopover() would be non-modal dialogs, dialog.showModal() would be modal.

I don't think there would need to be a need to rename popovertarget after this.

[jakearchibald]

Ugh, yeah, it's unclear what <button openertarget="foo"> would do with <dialog id="foo" popover>.

The "'open' can mean many things for one element" issue strikes again.

I'm happy for this issue to close on that basis, unless anyone has any bright ideas.

[keithamus]

I'm guessing "openertarget will call showModal() on <dialog> but showPopover() on <dialog popover>" isn't going to fly? Or what about "openertarget expects either a <dialog modal> or <dialog popover>"?

[hidde]

It seems to me that though it's unlikely to want make a modal dialog openable via an attribute (incl the drastic consequence of making the rest of page inert), but are there no use cases at all?

I do like @keithamus's last suggestion. Unless it's really heard to do, would love to see something like that exist.

[jakearchibald]

@hidde

(incl the drastic consequence of making the rest of page inert)

I've heard this said a few times, but not really understood it. Why is it drastic, and why is it more drastic when it can be done via a button rather than via JavaScript via a button?

@keithamus

I'm guessing "openertarget will call showModal() on <dialog> but showPopover() on <dialog popover>" isn't going to fly?

Just seems a bit arbitrary.

Because, then, folks will very reasonably ask for a way to use a button to open a dialog-popover as a dialog. And then we may as well have an attribute for each.

[hidde]

I've heard this said a few times, but not really understood it. Why is it drastic

Because as a website you're denying users access to anything on the page but this one thing? Sometimes it is the sensible thing to do, but it's drastic.

why is it more drastic when it can be done via a button rather than via JavaScript via a button?

Fwiw I'm not convinced declarative / via a button makes it any more drastic than doing it via JS, they are the same to me.

[hidde]

(Maybe also relevant to this is that a dialog can already be closed declaratively via a form with method=dialog)

[jakearchibald]

Sure, but having a delete button declaratively show an "Are you sure?" modal <dialog> seem fine? Light dismiss still works etc etc.

[keithamus]

At the risk of sparking debate on the particulars, a modal dialog is effectively a navigation to a smaller page. I don’t think it is any more drastic of a shift than a page navigation. Conversely expecting people to write JavaScript to wire up a button can create inconsistencies with interactions which results in arguably more frustrating consequences, for example missing out on one of the Enter/Space/Click/Touch actions (I literally had a bug report today regarding exactly this issue).

[hidde]

Agreed! One difference I can think of is that on a new page of the same website you'll have certain fixed things still as they were on the previous page, like a header, navigation etc. With a screenreader you could jump to those with shortcuts if in a new page, but not if in a modal (would say less consistent navigation).

[jpzwarte]

So what about the case where a button hover will show a tooltip (delayed popover="hint") and a click will show a dialog? Would this exclude that scenario?

[keithamus]

That's a very important use case to capture! Thanks @jpzwarte! It's enough to convince me that popovertarget shouldn't be made generic.

[jpzwarte]

See #3567 (comment)

[annevk]

I'm going to close this as we can't really reconsider the attribute names at this point.