<dialog>: The Dialog Element

Overall view of <dialog> and web standards

• Many see <dialog> as a net win: a standard, built‑in way to do modals without “flavor‑of‑the‑month” JS frameworks, especially for internal tools.
• Others describe the API as “messy” and only mediocre, emblematic of how web standards are valuable mainly because they are ubiquitous, not because they’re well‑designed.

API design, standards process, and history

• Some criticize that <dialog> was pushed into all browsers despite long‑standing accessibility/security concerns and only fixed later.
• Others counter that those issues were eventually resolved via spec updates and implementations.
• There’s frustration about the “living standard” process and perception that legacy APIs like alert/confirm/prompt are being nudged out without equally simple replacements.

Styling, UX, and native look

• A major disappointment: <dialog> is almost unstyled by default. Some had hoped for OS‑native looking, movable dialogs; instead it feels like a “glorified div.”
• Several argue this blank‑slate behavior is correct: most sites have custom design systems and need full control; heavy UA styling is hard to undo.
• Disagreement on whether native‑looking controls are desirable vs. brand consistency. Many note a broader pattern: native widgets (date pickers, media controls) look different across browsers and are often avoided.

Modals, accessibility, and top layer behavior

• <dialog>’s modal behavior (focus trapping, top layer) is generally praised for accessibility, but there are complaints about edge cases: scroll events bubbling, inability to adjust z‑index, and clashes with AdSense interstitials.
• Debate over modals themselves: some say they’re overused and user‑hostile; others argue they’re essential for multi‑step workflows and simpler state management.
• Concerns about dark patterns and user‑locking dialogs are raised, with pushback that any element can be abused.

JS reliance, forms, and alternatives

• Some dislike that opening/closing dialogs generally requires JS; desire CSS/HTML‑only control is mentioned, with “invokers” and popover attributes cited as partial answers.
• Reported quirks include form submission unexpectedly closing dialogs and limited event hooks to intercept closing.
• Several people experiment with async/await‑style wrappers around dialogs as non‑blocking alert/confirm/prompt replacements, often built on showModal() or popover.