2022-04-21
1159
#html
Amit Merchant
101214
Apr 21, 2022 â‹… 4 min read

Why you should be using the dialog element

Amit Merchant Software developer, writer, artist, and noob gardener.

Recent posts:

Fix over-caching with dynamic IO caching in Next.js 15

Next.js 15 caching overhaul: Fix overcaching with Dynamic IO and the use cache directive.

David Omotayo
Aug 6, 2025 â‹… 10 min read
LLMs are facing a QA crisis here’s how we could solve it

LLMs are facing a QA crisis: Here’s how we could solve it

LLM QA isn’t just a tooling gap — it’s a fundamental shift in how we think about software reliability.

Rosario De Chiara
Aug 4, 2025 â‹… 7 min read

Windsurf vs. Cursor: When to choose the challenger

Windsurf AI brings agentic coding and terminal control right into your IDE. We compare it to Cursor, explore its features, and build a real frontend project.

Chizaram Ken
Jul 31, 2025 â‹… 9 min read

The CSS if() function: Conditional styling will never be the same

The CSS Working Group has approved the if() function for development, a feature that promises to bring true conditional styling directly to our stylesheets.

Ikeh Akinyemi
Jul 30, 2025 â‹… 12 min read
View all posts

3 Replies to "Why you should be using the <code>dialog</code> element"

    1. Hey Karol,

      By using it in the production I meant the dialog element is supported by all the modern browsers except a few obscure browsers, such as IE, Opera Mini, KaiOS browser, UC browser etc, that still doesn’t support the dialog element.

      The market share of these browsers is fairly low at this point. And that’s why I said it’s safe to use it in the production.

  1. You can use another way that is much simpler for detecting outside click:

    “`
    const listener = (event: Event) => {
    if (
    event.target !== collectEmail &&
    event.composedPath().includes(collectEmail)
    ) {
    return;
    }

    // clicked outside the `collectEmail `
    };
    “`

    You’re welcome 🙂

Leave a Reply