Page MenuHomePhabricator

Design and build dropdown Menu component
Closed, ResolvedPublic


Component Design


The DropdownMenu component needs to be designed and specified before its implementation as part of the TypeaheadSearch component.

Screenshot 2022-03-23 at 15.49.58.png (532×797 px, 116 KB)

This Figma file contains the specifications for the Dropdown Menu component.

User stories

As a designer and developer, I need to be able to reuse a system-compliant DropdownMenu, in order to combine it with components that need to display a list of selectable items (such as Dropdown/Select, Combobox, Lookup, TypeaheadSearch).


  1. The DropdownMenu component wraps a list of MenuItems (see design task: T300625)
  1. The Menu component should display and accommodate (in terms of height) a number of items that is set by default. The number should of course be overridden in case that the available number of options < default number of displayed items. This number should be based on current patterns and probably be between 6 and 8 (to be validated with the rest of the PatternLab team). (Not part of this task's acceptance criteria; will be handled in T306932)
  1. Implementers of the component should be able to define the number of items to be displayed by default. Recommendations regarding the minimum (3) and the maximum (10) number of items will be provided. (Not part of this task's acceptance criteria; will be handled in T306932)
  1. Implementers of the component should be able to enable (or disable – depending on what we consider to be the default) the scroll functionality (Not part of this task's acceptance criteria; will be handled in T306932)
  1. The menu can display a loading state: initially, due to e.g. an API delay; or as a way to indicate that options are being refreshed (in case it's combined with a typeahead input)
Development considerations

The DropdownMenu is what can be considered a "subcomponent": a system element that can only accomplish its purpose when combined with some types of input. We might want to document this fact (as well as allowed combinations) as part of the component's documentation to prevent potential misuse.

Acceptance criteria (or Done)

  • All the interactive states and behavior of the DropdownMenu (based on the current visual design) are documented.
  • All the visual properties of the DropdownMenu are specified
  • Keyboard navigation support is defined

Component implementation


This component (called Menu) has been implemented in Codex, but is missing some new elements.

Acceptance criteria

  • All elements of the design spec are met and approved by the design team
  • New version of the component meets accessibility standards
  • New Menu features are demonstrated on the docs site


Other Assignee

Event Timeline

Sarai-WMDE renamed this task from Design OptionsMenu component to Design DropdownMenu component.Feb 10 2022, 5:33 PM
Sarai-WMDE updated the task description. (Show Details)
AnneT renamed this task from Design DropdownMenu component to Design and build DropdownMenu component.Mar 9 2022, 9:55 PM
AnneT updated the task description. (Show Details)
STH triaged this task as Medium priority.May 1 2022, 1:20 PM
AnneT renamed this task from Design and build DropdownMenu component to Design and build dropdown Menu component.May 5 2022, 1:15 PM
AnneT updated the task description. (Show Details)

Hey, @AnneT I believe that everything under "Component implementation" is referring to the scroll behavior of the Menu, which is captured by T306932: Add configurable scroll behavior to the Menu component. Should we remove that content from here? We could just add a reference to the scroll task, since they're not related.

@Sarai-WMDE I totally agree; I've updated the task description so we can remove scroll behavior from this task's acceptance criteria.

DAbad updated Other Assignee, added: EUdoh-WMF.
DAbad added a subscriber: DAbad.

This ticket simply needs QA. Otherwise work is complete here.

Test results are described here. I will be discussing with the team about these today.

Hi @Sarai-WMDE , I performed a test using a slow internet connection and I noticed the thumbnails were plain white before they eventually loaded the image. Should we have a default "no image thumbnail", like the first item in the screenshot below?

image.png (1×1 px, 321 KB)

Great catch! Thanks a lot, @EUdoh-WMF 🙏🏻 I agree: displaying the placeholder thumbnails as such until the images can be loaded would be ideal. I'd happily create a new task capturing this behavior if we get thumbs-up on the feasibility side from @AnneT and @Catrope.

+1, sounds like a good plan!

Thanks for taking care of creating the improvement ticket @Sarai-WMDE .

DAbad claimed this task.