Patterns

Required Fields

Required fields inform the user which inputs are necessary to fill out to complete or move forward in an experience.

Required Fields Indicator

Any input field that requires interaction or information collection from the user must be marked with a red asterisk next to the input field’s label. An optional input field shouldn’t have any additional text or icons next to its label to indicate it’s optional.

Example of a required input field with the red asterisk indicator.
Example of an optional input field with no icons next to the label.

Required Fields Text Placement

Whenever there are asterisks indicating required fields in a page or container, it’s important to inform or remind users what they mean. We use a standard message for this purpose: “Fields marked with * are required.” This message is displayed prominently inside the page or container, either in the header or in the content area.

Example of the required fields text placement inside a header.
Example of the required fields text placement inside the content area.

Do’s and Don’ts for Required Fields

Do:

  • Use the red asterisk to indicate all required fields.
  • Ensure the required fields text is placed in a prominent location and clearly connected with the required inputs’ asterisks.

Don't:

  • Use any indicators for optional fields.
  • Place the required fields text in a place where users may easily miss it.
  • Repeat the required fields text in multiple locations for one context.

In a compound component like Select or Action Menu, child components are rendered in the parent's slot element, part of its shadow DOM tree. Slots essentially serve as a placeholder for markup that you the developer define in the light DOM tree, like <wm-menuitem>, <wm-option>, text content, or other child elements.

The browser distributes the child elements defined in the light DOM into the shadow DOM of the parent. The result is a flattened DOM tree—a merger of the the light DOM and the shadow DOM. This flattened tree is what you see in DevTools and what is rendered on the page.

With the standard implementation of the component, dynamically updating the child items will throw an error. Elm's efficient diffing of the DOM will register that only the child items have changed and try to update them, but the component has already been composed.

Rendering the component in a Keyed node and giving it a dynamic id will cause the entire component, rather than just the child items, to render anew, avoiding the error.