Thoughs and records on IoT, Web Sites and Microprocessors.

Dialogs and Data

Sketch of a dialog with data input elements

Using modal dialogs for capturing user input and data in a web application Using the <dialog> and <form> elements requires repeated JavaScript logic. This can be streamlined by creating web components that extend the standard elements.

Modal dialogs have long been unsupported as native UI elements in browsers. Many early attempts to implement modal dialogs relied on overlays and additional HTML elements to mimic modality. These solutions created elements on top of the existing HTML document to simulate modal behavior and these libraries can still be found in use as of today. Since 2022, most modern browsers widely support modal dialogs via the <dialog> element.

The [SFC library] now has 2 new components to support the use cases for dialogs with nested forms.

Modal Dialogs Best Practices

Using modal dialogs is sometimes, but not always, the best choice for user interactivity. In general, focusing the user’s attention on specific information, asking for input in a strict step-by-step process, or requesting confirmation can really raise user acceptance of a solution.

From my experience I like to see the following when using modal dialogs:

No mouse trap. Any dialog should have the possibility of being closed without any action taken making the HTML page accessible again.
Modal Dialogs are presented with a backdrop and a common overall UI.
Pressing the Enter key works for the default action
Pressing the Escape key works for closing without action
A click on the backdrop may close the dialog as well, but this can sometimes happen by accident; consider accessibility concerns and user expectations, as some users may not expect dialogs to close this way or may inadvertently lose their progress.
Avoid displaying multiple dialogs at the same time. Nested modal dialogs should only be used in well-understood scenarios where users expect and can easily navigate them.
No Sheets. (“Sheets” are UI patterns where multiple forms are linked in a sequence, often sliding in from the side or bottom, to capture complex input from users.) Modal Dialogs are always initiated by a user activity. The “Sheet” approach by linking multiple forms in a sequence is a different implementation pattern also often used to capture complex input from users.
Dialogs are not panels. Non modal dialogs better have a UI approach seen as “Panels” that can stay at the side of the main document.
Dialogs should not be used for informing about non-critical messages. Better to have a “Toast” UI approach for informing about processing progress and issues. However in critical situations a modal information is helpful and modal dialogs are better that just using window.alert("...").

Dialogs and Data

Dialogs are often used for capturing or displaying data. Therefore many of them contain forms and functional buttons and this is maybe the most often used pattern of modal dialogs in general. This seems to be known to the people that have defined the standard elements of the Browser where “dialog” is a method of <form>. However the implementation is somehow incomplete and some common javascript is required to use “modal forms with dialogs”.

Here 2 custom elements help in the implementation

[u-dialog-form component] – This is a custom control that extends the <dialog> element to better support the combination of a form inside a dialog.
[u-form-json component] – This is a custom control that extends to the <form> element to better support JSON data that can be handled locally without reloading.

Dialogs and Data

Modal Dialogs Best Practices

Dialogs and Data

See also

Tags