dialog

22 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Dialog component purpose and use cases

Dialog is a floating surface used to display transient content such as confirmation actions, selection options, and more. Dialogs streamline the interface by allowing extra content to be disclosed as needed and create a new modality to the user, expediting the completion of individual tasks.

Dialog header region requirements

The header region provides context for the Dialog and supports a title, description, and a close button by default. The title is required for all Dialogs but may be visually hidden for custom scenarios such as a command palette. The close button is required and may not be visually hidden. The title has a default size along with a larger option for confirmation dialogs. The header region may include a custom content slot in place of the default title/description, though a title is still required. Secondary action icon buttons may be placed next to the close button.

Dialog subheader region purpose

The subheader region is an optional space for interactive controls. Use it to display a search field, a filter menu, or a local navigation component.

Dialog body region behavior

The body region is the main content of the dialog and can contain any content relevant to the task at hand. The body region is scrollable if the content exceeds the height of the dialog.

Dialog footer region placement and usage

The footer region may be used to show confirmation actions, navigation links, or specialized actions. Primary actions should be aligned to the right of the footer and grouped by additional related actions. Secondary actions may be shown aligned to the left side. If the content area has overflow scrolling, a divider should be added between the footer and content area. Otherwise, showing a divider is optional.

Dialog backdrop behavior

Dialog displays with a backdrop, which dims the rest of the page. By default, clicking on the backdrop will dismiss the dialog. However, if the dialog contains a form that can have unsaved changes, the backdrop won't dismiss the dialog, regardless of the state of the form.

Dialog content spacing safe area

The edges of dialog are free of text and heavy visuals to visually distinguish the dialog as an elevated surface. Content within the body and header should remain within a 16px safe area. Inner components that have transparent or discrete backgrounds may bleed into the padding for visual alignment. The close button is placed 8px away from the edges, with the glyph remaining within the safe area.

Dialog sizes: Small

Small dialogs have a width of 320px and a maximum height of 256px.

Dialog sizes: Medium (default)

Medium is the default size for Dialog and should be used for most tasks such as completing a form or selecting an option from a list. Medium dialogs have a width of 480px and a maximum height of 320px. Medium portrait oriented Dialogs have a width of 480px and a maximum height of 600px.

Dialog sizes: Large

Large dialogs are suitable for content that requires more horizontal space for the body compared to size medium, such as a comment box. Large dialogs have a width of 640px and a maximum height of 432px.

Dialog sizes: Extra large

Extra large dialogs have a width of 960px and a maximum height of 600px. Before using an extra large dialog, consider whether or not the content would be more appropriate for a new page.

Dialog sizing constraints

Each dialog size defines a width and a maximum height. By default the dialog height will adjust to the body content. If the maximum height is reached, the body contents will scroll. Dialog sizing is constrained by the viewport dimensions and dialogs will not grow beyond the boundaries of the viewport. All dialogs need to work on viewports of at least 320px of width and 256px of height.

Dialog content design guidance

Dialogs are meant to be interacted with in a single context. Avoid creating a whole page inside a dialog. Prefer single-column layouts that convey a clear goal from the moment the dialog is opened. Dialogs are powerful tools when creating space for single-context interfaces.

Dialog nested dialogs limits

It is acceptable to have up to two nested dialogs as long as the dialog is implemented with expected focus management behavior. Upon closing the second nested dialog, focus should return to the trigger control within the first dialog. When the two stacked dialogs are open, pressing Esc should only close the top-level dialog. When one clicks outside of the second dialog with a mouse, only the second dialog should close. Having more than three nested dialogs is discouraged because it adds unnecessary complexity to the user experience and can be disorienting for some users.

Dialog deep linking considerations

It is crucial to consider if the dialog should be accessible via a link. While parameters in the URL can open dialogs on page load, this approach can disorient users because they might not understand to what context this dialog belongs since the rest of the page will be dimmed by a backdrop. In such situations, it is often more advisable to avoid using a dialog altogether and instead display the additional information directly on the page or create a new dedicated page.

Dialog responsive behavior on mobile viewports

Dialogs must adjust their designs to fit in smaller viewports. Make sure the overlay contents work with all supported sizes and input methods. Center aligned dialogs become fullscreen or bottom sheets on narrow viewports.

Dialog centered placement

By default, dialog appears centered in the viewport, with a visible backdrop that dims the rest of the window for focus. Centered dialogs are surrounded by a safe area of 16px between the frame and the viewport for all sizes.

Dialog left side sheet placement and usage

Left side sheets are reserved for global navigation drawers. Side sheets slide from the left edge of the viewport and are always fixed to both the top and bottom of the viewport. Side sheets take the entire height of the viewport and should be used sparingly.

Dialog right side sheet placement and usage

Right side sheets are used for global actions, but can also be considered for quick previews in full-width pages. Right side sheets slide from the right edge of the viewport and are always fixed to both the top and bottom of the viewport. Side sheets take the entire height of the viewport and should be used sparingly. Don't use side sheets to present create/edit forms, or flows that may contain a lot of information. Exercise caution when implementing side sheets in pages that are not full-width to minimize the distance users need to travel with their mouse cursor to access the side sheet.

Dialog side sheet backdrop requirement

Side sheets are still considered as dialogs, which means interacting with the content in the background is not possible. This needs to be indicated by a backdrop and should always cover the global navigation. This prevents multiple side sheets from appearing simultaneously.

Dialog bottom sheet on narrow viewports

A bottom sheet is a variant supported on narrow viewports made to facilitate reachability. Dialogs that appear centered in large screens may adapt to appear as a bottom sheet on small screens. A bottom sheet always dims the rest of the screen for focus and takes up the full width of the viewport. Tapping on the backdrop dismisses the dialog. In landscape mode, a bottom sheet has a maximum width of 480px and is centered horizontally.

Dialog full-screen variant on narrow viewports

Full-screen dialogs may be used to present content that needs all the available space on narrow viewports, or to act as a new page without navigating away from the main page. Dialogs that have one or more input fields should always use the full-screen variant.

Give your agent this brain