Page MenuHomePhabricator

[EPIC] Define Codex's approach to responsiveness
Open, Needs TriagePublic



We want Codex users to be able to utilize components that have a built-in responsive behavior, making them automatically display correct and consistent visual properties across viewports.

Our objective is to allow library users to deliver seamless responsive experiences without needing to provide explicit instructions or adjustments, while still allowing for rare cases where manual sizing might be necessary.

To enable that, we need to establish a general responsive design and implementation strategy for Codex components, so we can offer a solution that's adaptable to products, with or without skins.


  • Codex components shouldn't rely on skins to adjust to desktop and mobile web contexts
  • All Codex components should display consistent and optimal visual properties (height, font-size, line-height, spacing) under the same responsive scenarios
  • Our solution needs to accommodate for component sizing (see T338021). System users should be allowed to apply different sizes to components in different environments (TBD if that involves overriding their responsive properties, see Open questions).

Open questions

  • Built-in responsiveness vs. Minerva: When defining the visual properties (sizing, spacing, font style) of the responsive/mobile version of Codex components: How much do we need to keep Minerva in mind? Are we allowed to deviate from it (and potentially create inconsistencies)? Or can we somehow influence Minerva styles to make them reflect/align with Codex styles?
  • Responsiveness vs. Sizing: How do we handle responsive sizing for components that have a "size" prop (Button: large/medium; Icon: medium/small/x-small)? Does size=large always mean the same regardless of viewport size (non-responsive), so that you have to set something like size=responsive or size={desktop: large, mobile: medium} to get responsive behavior? Or does size=large mean a different number on desktop vs. mobile? E.g. a large button on mobile would be larger than a large button on desktop, but within each platform a large button would always be larger than a medium button.
  • Documentation: Should our approach to responsiveness be documented in an ADR? If so, add to Acceptance criteria section.

Potential approaches

[⚠️ This section is work in progress ⚠️]

1. Breakpoint-based responsiveness

This approach would consist on defining “base” desktop, tablet (?) and mobile sizes for Codex components, and allowing users to alternate between those based on breakpoints, originally defined in T303522.

Breakpoint values would be recommended by the system (see Breakpoint tokens), but ultimately allow customization. This is so system users can optimize for their specific project's needs (i.e. keep a content-first approach).

Further information

1.1 Evaluate alternatives to width breakpoint based media queries before applying them across components and patterns

T344275: [Spike] Evaluate alternatives to current pixel based breakpoint approach for Codex responsiveness

Acceptance criteria

  • We design the responsive version of system components (T344368)
  • We document the responsive version of system components in Figma (T341192)
  • We define the implementation approach that would allow us to embed responsiveness into Codex components (T344369)
  • We apply the implementation changes required to embed responsiveness into Codex components (Task TBD)

Event Timeline

Sarai-WMDE renamed this task from [EPIC] Define approach to responsiveness to [EPIC] Define Codex's approach to responsiveness.Jun 27 2023, 11:10 AM
Sarai-WMDE updated the task description. (Show Details)
CCiufo-WMF triaged this task as Medium priority.Sep 8 2023, 11:18 PM
CCiufo-WMF raised the priority of this task from Medium to Needs Triage.Jan 16 2024, 3:26 PM