Page MenuHomePhabricator

FloatingUI: Integrate with existing menu height limit and sticky footer
Closed, ResolvedPublic2 Estimated Story Points

Assigned To
Authored By
AnneT
Sep 18 2023, 9:08 PM
Referenced Files
F41563001: Screenshot 2023-12-05 at 11.46.55 AM.png
Dec 5 2023, 4:48 PM
F41563003: image.png
Dec 5 2023, 4:48 PM
F41562456: image.png
Dec 5 2023, 11:10 AM
F41562455: image.png
Dec 5 2023, 11:10 AM
F41562444: After.png
Dec 5 2023, 11:08 AM
F41562442: Before.png
Dec 5 2023, 11:08 AM

Description

Background

T346099 covers implementing basic positioning of menus via FloatingUI in 3 components:

  • Select
  • Combobox
  • Lookup

This will be done in an internal composable, useFloatingMenu, so it can be applied to future menu components as well.

This task covers extending that composable to handle menus with a visibleItemLimit and/or a sticky footer. This should be implemented after T346689, which adds clipping and flipping behavior.

Requirements

Menus should:

  1. Always remain "attached" to their triggering element
  2. Always have an appropriate width (e.g. in most cases, menus are the width of their triggering element)
  3. Always be fully visible within the viewport and not extend past it
  4. Be able to extend past the bounds of their container

This should all work:

  • With the menu attached to the top or the bottom of the triggering element
  • With a static "footer" element under the menu that is always visible and pinned to the bottom of the menu
  • With a limited number of visible menu items (i.e. existing scroll)
  • With scrolling
  • With window resizing
  • In LTR and RTL

Implementation details

We will need to:

  • Ensure that clipping a menu via the composable meshes with the code in the Menu component that limits the menu height when a visibleItemLimit is set (e.g. there should only be a single scrollbar)
  • Ensure that a menu's sticky footer is always pinned to the bottom of the menu, with or without clipping or a visibleItemLimit

Acceptance criteria

Design:

  • Create the Figma exploration file with the updated menu component and update the Figma component in the library:
    • Menu items order is the same, either when the menu opens down or up. So sticky footer in both cases is placed at the bottom of the menu
    • Represent the visibleItemLimit prop in the Figma spec
  • Create a version with the menu opening upwards for all the Figma components using menu: Combobox, Lookup, and Select.

Code:

  • Menu positioning, flipping, and clipping works with:
    • A menu with a visibleItemLimit
    • A menu with a sticky footer
    • A menu with both a visibleItemLimit and a sticky footer

Event Timeline

CCiufo-WMF triaged this task as Medium priority.Oct 27 2023, 6:44 PM
AnneT set the point value for this task to 5.Oct 30 2023, 5:15 PM

Change 970903 had a related patch set uploaded (by Catrope; author: Catrope):

[design/codex@main] Menu: Improve scrolling behavior to play nice with useFloatingMenu

https://gerrit.wikimedia.org/r/970903

Change 972847 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] demo: Add menu with footer to the DialogDemo

https://gerrit.wikimedia.org/r/972847

Change 972927 had a related patch set uploaded (by Catrope; author: Anne Tomasevich):

[design/codex@main] Menu: Fix footer item being too wide

https://gerrit.wikimedia.org/r/972927

Catrope changed the point value for this task from 5 to 2.Nov 28 2023, 6:59 PM

Change 970903 merged by jenkins-bot:

[design/codex@main] Menu: Improve scrolling behavior to play nice with useFloatingMenu

https://gerrit.wikimedia.org/r/970903

Change 972847 merged by jenkins-bot:

[design/codex@main] demo: Add menu with footer to the DialogDemo

https://gerrit.wikimedia.org/r/972847

Change 972927 merged by jenkins-bot:

[design/codex@main] Menu: Fix footer item being too wide

https://gerrit.wikimedia.org/r/972927

AnneT changed the task status from Open to In Progress.Nov 29 2023, 6:15 PM

The menu in Figma was previously designed rotating all the menu items (included the sticky footer) when the menu was open on top.
I've revised the Figma component and spec sheet to reflect the updated behavior, ensuring that the menu items and sticky footer maintain their order whether the menu opens downward or upward.

So I've updated both:

  • Figma exploration file with this new version of menu order. I've also included examples for how the sticky footer behaves in both menu down and up and an example of the maximum number of possible menu items.
  • Figma main component in the library with these new behaviors.
image.png (536×639 px, 33 KB)
image.png (532×638 px, 37 KB)
BeforeAfter

@AnneT I've reviewed the menu in Codex with the new behaviors and it works well. The only inconsistency with the Figma component I've detected is that when the menu opens upwards, the shadow position doesn't change. The shadow should be:

  • Menu down: 0px **2px** 2px 0px(using box-shadow-drop-medium)
  • Menu up: 0px **-2px** 2px 0px (there is no any token created yet for this shadow)

Do we want to create a new shadow token for the position (down / up) of the shadow? cc: @Volker_E

Are we sure we want to change the shadow when it opens up? It feels kind of natural to me to lack the shadow on top of the menu when it's opening up.

image.png (466×1 px, 27 KB)

If you do flip the shadow, it looks like this:

Screenshot 2023-12-05 at 11.46.55 AM.png (472×1 px, 31 KB)

I would argue for keeping the shadow if we were using one with a more "diffused"/ambient type of style (like the one Ant Design applies to menus), but I think it makes sense to lack this specific drop shadow when the menu opens upwards, yes. The border already provides sufficient contrast against the background. This way, we'd keep the placement of the light source consistent. My bad again for including this style in the original exploration, which definitely needed a review.

Change 980902 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/core@master] Update Codex from v1.0.1 to v1.1.1

https://gerrit.wikimedia.org/r/980902

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d419984345/w

Change 980902 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.0.1 to v1.1.1

https://gerrit.wikimedia.org/r/980902

bmartinezcalvo subscribed.

Are we sure we want to change the shadow when it opens up? It feels kind of natural to me to lack the shadow on top of the menu when it's opening up.

image.png (466×1 px, 27 KB)

If you do flip the shadow, it looks like this:

Screenshot 2023-12-05 at 11.46.55 AM.png (472×1 px, 31 KB)

@AnneT after commenting about this in our last DST design sync, we've decided the following:

  1. We will go with this version of the menu following the same behavior as we have in the OOUI version: the menu items will not be reorganized when the menu opens upward, and the shadow will remain the same in both the downward menu and the upward one.
  2. Since there are some use cases where the reorganization of menu items could be necessary, we will create a new task to test with real users in the future both versions of the upward menu (with items non-reorganized and with items reorganized) to collect real feedback about this.

So we can go for now with this menu. Since the menu with these updates is working correctly, we can move this task to Pending Release and open another new task to evaluate and test the menu with users in the future.

and the shadow will remain the same in both the downward menu and the upward one.

Clarification: our agreement was to actually lose the shadow when the menu opens upwards (See DST Design sync notes). No modifications need to be made to the current implementation when it comes to the menu items' order or the menu's shadow.

and the shadow will remain the same in both the downward menu and the upward one.

Clarification: our agreement was to actually lose the shadow when the menu opens upwards (See DST Design sync notes). No modifications need to be made to the current implementation when it comes to the menu items' order or the menu's shadow.

That last comment was incorrect. I misinterpreted Bárbara's sentence. When the menu opens upwards, the drop shadow is preserved. The shadow we're dropping is the one that could have been displayed at the top (see https://phabricator.wikimedia.org/T346696#9383855).

This was included in the last Codex release so I'm resolving it!

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/d419984345/w/