In our work to improve and address the feedback received for the submenus interactions we need to replace the flyout with a "drawer".
Note: This designs show also part of the explorations happening around the admin UI layout redesign and are not part neither from this issue nor the Navigation module.
With the goal to divide the work in several issues to work in parallel, this issue is aimed to implement the main drawer behavior, leaving for follow-ups style refinements and the accordion behavior inside the drawer.
We need to ensure the drawer works well across all viewports.
This following gifs taken from a Figma prototype show a high-level idea of the interaction expected (technical requirements can make some of these animations and interactions vary slightly):
Somenteraction notes:
Implement the drawer.
The submenus interaction will change radically from flyouts to a drawer pattern.
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | screencast 2024-03-28 09-19-02.gif | 636.34 KB | ckrina |
| #14 | screencast 2024-03-27 18-40-27.gif | 379.07 KB | ckrina |
| #6 | toolbar-prototype.png | 104.25 KB | ckrina |
| #6 | collapsed-navigation-interactions.gif | 547.97 KB | ckrina |
| #6 | non-collapsed-navigation.gif | 498.09 KB | ckrina |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
starshapedComment #3
bronzehedwickComment #6
ckrinaAdding more definition and screenshots on the IS to define and limit the scope.
Comment #7
ckrinaComment #9
bronzehedwickOkay, I pushed fixes for the above. Now:
These aspects are ready for review.
TODO
There's an outstanding issue with
z-indexlevels for the submenu drawer animation. The submenus should slide out from behind the navigation, and this works, except for the footer element, which is a sibling of the content nav. This causes the footer submenus to animate over the navigation.Would it be okay to move the footer nav inside the content nav, and achieve the same visual effect via CSS? I'm not sure if there are accessibility implications here. Screenshot of potential markup below.
Comment #10
bronzehedwickI pushed a fix for the footer submenu
z-indexissue, above, without any markup changes, and should now be fixed.While fixing that issue, I noticed the mobile submenus don't have the correct size across screen sizes, so I'm looking into that now.
Comment #11
bronzehedwickI've pushed a fix for the mobile submenu size issue, above. All known issues have fixes applied. This issue is now ready for review.
Comment #12
bronzehedwickComment #13
finnsky commentedI see few issues on mobile and desktop js behaviour. i would like to have them fixed aswell.
Comment #14
ckrinaThis is looking great! Almost there :D
I'm still seeing the error where, after opening one of the main parent items, it doesn't close when I hover another item:
Comment #17
rkollerone detail i've noticed, if you open up a submenu you then have the label of the top level menu item as the "heading" now. That heading is clickable by the mouse but it has an invisible focus outline when you tab through the menu by keyboard (ref wcag sc 2.4.7 - focus visible).
Comment #18
bronzehedwickConfirming receipt. Working on the issues outlined.
Comment #19
bronzehedwick@ckrina Woops, I forgot to fix dismissing the submenu on hover out. Pushed a fix for that!
Comment #20
ckrinaMoving it back to Needs work because @finnsky is working on JS fixes.
Comment #21
finnsky commentedComment #22
finnsky commentedComment #23
ckrinaAs mentioned yesterday in Slack, I'm still seeing weird behaviors and I think it's related to the fact that the open/close is reacting to hovering something else, when the event to trigger that change should be related to the element itself you’re interacting with. For example, if I leave the user menu to click on the collapse button, that should close its child drawer. But doesn't:
Moving to Needs Work to draw attention to this, because if an event as key like this needs to be changed it's better to do it in this issue.
Comment #24
finnsky commentedThis one is ready to go.
Comment #26
ckrinaAnd merged! Thanks everybody involved, specially @bronzehedwick and @finnsky for the great work and collaboration with this time-sensitive key feature!