Page MenuHomePhabricator

Codex MenuItem with link click target is too small
Closed, ResolvedPublic

Assigned To
Authored By
SToyofuku-WMF
Mon, Jul 20, 6:23 PM
Project Tags
Referenced Files
F94881250: image.png
Mon, Jul 20, 6:23 PM
F94880387: image.png
Mon, Jul 20, 6:23 PM
F94880293: image.png
Mon, Jul 20, 6:23 PM

Description

Background

For codex Menus or Selects, if the individual menu items are links with urls specified, the padding is not factored into their click target, making it possible for you to select the option by clicking around the edge of the menu item rather than triggering the link

image.png (550×260 px, 25 KB)

image.png (550×260 px, 25 KB)

pointer is not visible, but note the difference in hover states

This can be reproduced on the Codex MenuItem page, either by inspecting the element or observing the clickable surface of the item

User story

As a user, I don't want to accidentally misclick and select an item in a list without it properly linking me to a separate page

Design requirements

Add design requirements or link to design files.


Requirements

Acceptance criteria

  • For MenuItems with URLs, clicking anywhere in the entire MenuItem, including padding, will take you to the link
  • MenuItems without URLs are unaffected
  • All MenuItems have the same padding and appearance as before

QA strategy

  • Risky change? Potentially high risk due to impacting all MenuItems - potentially lower risk if the change can be scoped to only those with url specified
  • QA by: QS, PM, and engineering
  • QA in: Any/all
  • Test steps: Inspect the element, hover over the a tag and observe that it doesn't look like this

image.png (634×162 px, 36 KB)

or if it does, that the surface outside the smaller box is still clickable

Communication criteria

Unclear if this should be announced in any way since it's a Codex change

Rollback plan

I would expect this to all be accomplished using JS and CSS, so should be easy to revert if broken

Details

Related Changes in Gerrit:

Event Timeline

Les4353 changed the task status from Open to In Progress.Mon, Jul 20, 6:43 PM
Les4353 claimed this task.

We won't need a communication plan for this, just need to ensure we don't break existing implementations as you said in the task (especially TypeaheadSearch, which uses the URL feature of MenuItem)

Change #1312572 had a related patch set uploaded (by Les4353; author: Les4353):

[design/codex@main] MenuItem: Let URL item be full-width

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

The problem here is that the MenuItem's padding is on the <li> element, which is the parent of the <a> element for MenuItems with URLs. We did this because you the default slot also sits here, and we wanted to ensure that all MenuItems have the same padding regardless of whether the default content or the slot is used.

One thing we could do is give .menu-item__content (that's the class of the <a> element, or the <span> if there's no URL) a negative margin and positive padding equal to the <li> element's padding. I think that would fix the issue, but we'd want to make sure it wouldn't have any negative consequences.

The problem here is that the MenuItem's padding is on the <li> element, which is the parent of the <a> element for MenuItems with URLs. We did this because you the default slot also sits here, and we wanted to ensure that all MenuItems have the same padding regardless of whether the default content or the slot is used.

One thing we could do is give .menu-item__content (that's the class of the <a> element, or the <span> if there's no URL) a negative margin and positive padding equal to the <li> element's padding. I think that would fix the issue, but we'd want to make sure it wouldn't have any negative consequences.

Thanks, I learned that and the patch is corrected now!

Change #1312572 merged by jenkins-bot:

[design/codex@main] MenuItem: Let URL item be full-width

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