{"id":5578,"date":"2025-04-16T16:54:36","date_gmt":"2025-04-16T21:54:36","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=5578"},"modified":"2025-05-26T14:57:11","modified_gmt":"2025-05-26T19:57:11","slug":"lessons-learned-from-recreating-a-styled-dialog","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/lessons-learned-from-recreating-a-styled-dialog\/","title":{"rendered":"Lessons Learned from Recreating a Styled Dialog"},"content":{"rendered":"\n

I was on the epicgames.com website the other day, signing up so I could relive my Magic: The Gathering glory days with Arena. While doing that I saw their style for modal dialogs and thought I should try to re-create that with <dialog><\/code><\/em> because apparently I’m both of those types of nerd.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

It’s a <dialog><\/code><\/h2>\n\n\n\n

This thing came up on top<\/em> of other content, so that alone makes it appropriate for the HTML <dialog><\/code> element. We’ll use that.<\/p>\n\n\n\n

No Taller than Viewport<\/h2>\n\n\n\n

It’s not absolutely required that the entire <dialog><\/code> needs to be shorter than the viewport. If it’s taller, you just need to be able to scroll to all of the content it contains. The default styling for <dialog><\/code> allows for that. <\/p>\n\n\n\n

But I would argue that if you’re putting actions that relate to the content of the dialog at the bottom<\/em> then you should<\/em> limit the height of the dialog to the viewport so that those actions are always visible. If a dialog simply has an \u2715 close button on the top, maybe it doesn’t matter, but here we’ve got important buttons at the bottom, so it does. <\/p>\n\n\n\n

The default styling for dialog includes position: absolute;<\/code> and we can keep that while limiting the height like:<\/p>\n\n\n

dialog<\/span> {\n  block-size<\/span>: 90<\/span>dvb;\n  inset-block-start<\/span>: 5<\/span>dvb;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
That will limit the height to essentially 90% of the viewport height (the dv<\/code>b part means “d<\/strong>ynamic v<\/strong>iewport size in the b<\/strong>lock direction”). I like the “dynamic” sizing units because it means that it accommodates browser “chrome” (toolbars and stuff) being present (or not). The inset amount is half of what’s left over, so essentially vertical centering.<\/p>\n\n\n\n
\"\"
This graphic convinces me dynamic viewport height units are a good idea. (source<\/a>)<\/figcaption><\/figure>\n\n\n\n
Note that the dialog element’s default styles can be a bit confusing and you need to understand when you can override safely and when you can’t without doing extra work. Simon Willison has an interesting article on this: Styling an HTML dialog modal to take the full height of the viewport<\/a>.<\/p>\n\n\n\n
Limited Width and Centering<\/h2>\n\n\n\n
This example has lots of written content in it (a bunch of <p><\/code>s) so it’s best practice to limit the width to a readable line length. When that’s the intent, it’s nice to use the ch<\/code> unit as it maps roughly to number of characters, which is what we’re trying to limit. <\/p>\n\n\n
dialog<\/span> {\n  ...\n\n  inline-size<\/span>: min<\/span>(50ch<\/span>, 90<\/span>dvi);\n  margin-inline<\/span>: auto;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Fifty characters of width is providing good readability here, but it’s possible that the current screen is actually narrower than that, hence the min()<\/code> function assuring that the width will never be wider than 90% of the viewport. I’m not sure if our fancy dancy “dynamic viewport units in the inline direction” is buying us anything here, but it balances the usage with where we were using dvb<\/code>). <\/p>\n\n\n\n
\n
\n
\"\"<\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n
Modal vs Non Modal (and the open<\/code> attribute)<\/h2>\n\n\n\n
This seems like a pretty important distinction to know about:<\/p>\n\n\n\n
    \n
  • “Modal”<\/strong> (dialog.showModal()<\/code>) means interrupt everything else, this dialog needs to be dealt with immediately.<\/em>\n
      \n
    • The ESC key automatically works to close it. <\/li>\n\n\n\n
    • Focus is put on the first focusable element within the dialog<\/li>\n\n\n\n
    • Focus is trapped within the dialog<\/li>\n<\/ul>\n<\/li>\n\n\n\n
    • “Non Modal”<\/strong> (dialog.show()<\/code>) means the dialog is just there<\/em>, but doesn’t require exclusive or immediate action.\n
        \n
      • None of those other things above happen. You likely want to bind the ESC key yourself anyway.<\/li>\n\n\n\n
      • When you use the open attribute (useful when working on them!) like <dialog open><\/code> the dialog is open non-modally. <\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
        In our example, where a person needs to accept-or-not the Terms & Conditions, it’s likely modal <\/em><\/strong>is the better approach. That way what the person is trying to do can only continue if they accept or take a different path if they do not. This choice is likely required to know what to do next. <\/p>\n\n\n\n
        A non-modal dialog implementation might be something like a “site navigation drawer” where some of the attributes of using a modal is desirable (e.g. the hide\/show behavior) but focus trapping is not required or even desirable.<\/p>\n\n\n\n
        Here’s a video of focus trapping at work with the modal state. Notice the “focusable element” (an anchor link) never gets focus, because it’s not within the <dialog><\/code>. <\/p>\n\n\n\n\t\t
        \n\t\t\t