Lead: Liav Nadler
...
in the main workspace.
inside various containers, including dialog Dialog popups, popovers Popovers,wizardsWizards,filter Filter panes, details Details panes and cards Cards.
In the main workspace | Inside a | dialog |
 |  |
Usage & Behavior
Structure
...
the input area, which may contain any set of input fields, including text Text fields, dropDrop-down menus, checkboxes Checkboxes, radio Radio buttons etc.
the action area, which consists of:
A submit button, such as Save, Create, or Update.
an additional Cancel button, when shown inside a container.
additional actions, if needed.
...
For the usage and behavior of inline inputs, see Inline Inputs.
Where possible, field labels will appear above the input field.
Where relevant, a red mandatory indicator (*) will be shown next to the label.
Where relevant, a help icon will appear next to the label (aligned to the right side of the field, if possible).
...
The action area will always be visible.
Main action buttons are aligned to the right. If needed, buttons for secondary actions such as clear or delete will be aligned to the left.
Where the form takes up the entire workspace, the action area will appear at the top of the page. (See Examples below).
In all other cases, the action area will appear below the form.
In widgets within the workspace, the action area will be separated by a horizontal line.
If the form does not exceed the height of its container, the action area will appear below the last form field.
If the form exceeds the height of its container, the action area will stick to the bottom of the container, allowing users to scroll the form above it.
Inside other containers, the action area will appear at the bottom of the container (see Examples below).
 |  |
States
Forms can have two states:
Idle / Saved. Applies when entering a form or after clicking the Submit button. In this case, the Submit button is disabled.
Edited. Applies after making changes to the form but before clicking the Submit button. In this case:
the Submit button is enabled.
attempting to leave the form will trigger a confirmation message. See Validation and errors below.
...
Clicking the Submit button:
sends the data for further processing. (For error handling see Validations and errors below).
In the workspace, if the form was submitted successfully:
a success Toast will appear, and
if the form was triggered from a parent page, the user will be redirected back to that page.
For forms inside containers, refer to the corresponding pattern documentation (for . For example, clicking the submit button in a dialog Dialog popup, will close it).
Clicking the Cancel button, if exists, will:
trigger a confirmation message, if the form is in the Edited state, and then
close the container (unless pinned) without saving the data.
...
For input-specific validations see Field Validationvalidation.
A form cannot be submitted if one or more of its fields are in an error state. Here is a typical flow:
When entering a form, the Submit button is disabled. (The Cancel button, if exists, is always enabled).
On updating any field, the Submit button is enabled.
If there is an input error, the Submit button will be disabled again. Only after all errors have been resolved is it enabled again.
After clicking Submit, the button is disabled again.
In case the user tries to navigate away from a form after updating one or more fields or while there are errors:
a message popup will appear. (See the Common messages repository for wording).
the user will choose to either keep editing the form or leave and discard their changes.
...
Form fields should be arranged in one column. Closely related fields (e.g. first name and last name) may appear side by side.
Collections of related fields should be grouped into sections. For example, fields such as Email and Phone may be found under a Contact Information section.
Examples
 |  |
  |
Accessibility compliance
...