Problem

Reusers of the ProgressBar component have total control over the placement and size of the bar. This is necessary for flexibility, but can also lead to inconsistencies when this freedom extends to a common use case: indicating the loading of pages or page areas.

Suggested solution

To support the consistency of page (or area) loading indicators, Codex could document a recommended width for ProgressBar in the component's design guidelines.

The responsive behavior of the bar should also be documented (e.g. should it simply shrink when it doesn't fit in the viewport, or should it become full width at a specific breakpoint?).

Considerations and open questions

• From an implementation perspective: is it expected that the teams create a wrapper (as done in the Codex's demo) to apply said width to the bar? If so, this should probably be made clear in the technical documentation too (and added to the AACC below).

Acceptance criteria

• Codex's documentation on ProgressBar (Figma, Demo) specifies a recommended width for the use of the component in the context of page loading
• Codex's documentation on ProgressBar (Figma) specifies the responsive behavior of the component when displayed on a full page