dialog element
Valdi skips the JavaScript runtime by compiling TypeScript to native views. Learn how it compares to React Native’s new architecture and when the trade-off makes sense.

What trends will define web development in 2026? Check out the eight most important trends of the year, from AI-first development to TypeScript’s takeover.

AI-first debugging augments traditional debugging with log clustering, pattern recognition, and faster root cause analysis. Learn where AI helps, where it fails, and how to use it safely in production.

Container queries let components respond to their own layout context instead of the viewport. This article explores how they work and where they fit alongside media queries.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
3 Replies to "Why you should be using the <code>dialog</code> element"
it’s still not nearly supported enough to use in production, check caniuse – 76%
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.
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 🙂