Page MenuHomePhabricator

Apply responsive behavior to TypeaheadSearch menu
Closed, DeclinedPublic

Description

Background and goal

Currently, the menu of the TypeaheadSearch component in Vector 2022 takes, by default, the width of the input that triggers it, and it only expands to take the full width of the Search input + button when the viewport becomes smaller than 1000px. All in order to keep the content readable:

Screenshot 2022-05-09 at 16.38.13.png (1×2 px, 553 KB)

The Codex TypeaheadSearch component should incorporate this "responsive" behavior, and allow for the menu to expand to 100% of the component's width under certain conditions.

Considerations

The following suggestion should be verified with help from DST engineers and designers, and approved by the Readers Web team, but we think that the responsive version of the menu (its full-width mode) should be triggered by the width of the input, instead of the viewport's. Making the menu wider only in relationship to the viewport can cause issues like the following, where the menu is too small but doesn't adjust because the breakpoint doesn't apply (1024px):

Screenshot 2022-06-01 at 11.56.21.png (1×2 px, 989 KB)

In order to prioritize the correct visualization and selection of the menu's content, we'd like to recommend that the TahS menu becomes full-width when the input's width decreases below 384px (a multiple of the system's base unit, currently documented in our sizing scale).

Acceptance criteria

  • When the width of the TypeaheadSearch input becomes smaller than 384px, the TypeaheadSearch Menu becomes full width

Event Timeline

When taking this task on, be sure to discuss additional concerns with @Sarai-WMDE

Would be good to discuss in an engineering-design sync early next sprint!

STH lowered the priority of this task from High to Medium.May 26 2022, 5:19 PM

With T264218: Lower Vector min-width to 500px in place we should focus on >=500px sizes only for now.

Hey @Volker_E. The current recommendation would be to make the TahS menu's width relative to that of the input instead of the viewport's: so the menu would become full-width when the input becomes smaller than 384px (width extracted from spacing/sizing scale). If we decide to follow this approach (I'll involve the RW team once we're synced internally), then the recent min-width change wouldn't need to be observed.

Hey @Volker_E. The current recommendation would be to make the TahS menu's width relative to that of the input instead of the viewport's: so the menu would become full-width when the input becomes smaller than 384px (width extracted from spacing/sizing scale). If we decide to follow this approach (I'll involve the RW team once we're synced internally), then the recent min-width change wouldn't need to be observed.

Alright, makes sense to me.

Flagging for discussion with readers web to see if this is something for them to control within vector themselves or otherwise

This seems to already be working on the test wiki for the current Vector patch:

Screenshot from 2022-06-09 10-53-53.png (700×734 px, 115 KB)
Screenshot from 2022-06-09 10-54-05.png (704×1 px, 156 KB)

That's because the code for this is a single CSS rule in Vector, and updating that rule to use the equivalent Codex selector kept the feature working.

Minor adjustment: I don't have Volker-vision, but I think the bottom-end border radius for the button will need to be set to 0 in this case

Minor adjustment: I don't have Volker-vision, but I think the bottom-end border radius for the button will need to be set to 0 in this case

You clearly do, and that's right! I'm realizing I forgot to link the design specs

Minor adjustment: I don't have Volker-vision, but I think the bottom-end border radius for the button will need to be set to 0 in this case

You're absolutely right! I'll take care of that, I'm neck-deep in this Vector CSS right now anyway.

Sarai-WMDE closed this task as Declined.EditedJun 9 2022, 6:24 PM

The Readers Web and Design System teams agreed to let this responsive behavior be handled by Vector, and to not introduce it in the Codex TypeaheadSearch component at this point in time.