[somishere]

I love the <dialog> element, especially for its built-in / standardised accessibility considerations. I'm looking forward to the day I can roll it without a polyfill (once safari <15.4 drops out of our thresholds).

That said, my one major bugbear with it is the reliance on javascript. Yep, I expect all* users on my sites to arrive with JS enabled. But I also (selfishly?) derive some satisfaction from them not having to. Why can't I control the dialog's open state with CSS or a targeted button?

Would love to learn I'm wrong about this.

[Heliodex]

This is why I mainly use some other custom <div> with a popover="" attribute. They're easily targeted with a button and no clientside JS required, and can be closed by clicking outside them, which <dialog>s don't have by default. They also still have the same helpful top-layer properties.

Unsure about accessibility on this front, though it can't be worse than my previous attempts with hidden labels/checkboxes/form elements, while being much simpler and less hacky.

[somishere]

Re. accessibility, the main feature is that dialogs can be "modal" - meaning the rest of the page is non-interactive while the dialog is open - ensuring a focus trap.

Popovers are always non-modal, which can be problematic depending on the use-case. Of course it's possible to manually implement a focus trap, but it's complex and it's javascript.

[extra88]

Yes, I wish when the popover attributes were created there was something included for opening a modal dialog.

I think it is possible to use popover to open a dialog non-modally and use progressive enhancement to replace that behavior with `.showModal()`.

[jazzypants]

This is coming with invokers.

https://css-tricks.com/invoker-commands-additional-ways-to-w...