Using font size and spacing for mega menu hierarchy

[tyleralsbury]

Why are these changes introduced?

Further explorations on how to improve the hierarchy of the different navigation levels for the mega menu. In this PR we are trying removing the bold and instead using font size and spacing to help to emphasize the hierarchy.

What approach did you take?

Added a modifier. I tried to use some fancy selectors, but this was cleaner.

Other considerations

I used :not(:only-child) to ensure that L2 links on their own won't have additional margins.

We may want to fine tune the numbers for the margin below the L2 link as well as potentially the vertical gap between the rows. The total space below the L2 links including their padding is 1.8rem and the total space between rows is 2.4rem which is quite similar.

Testing steps/scenarios

• Add a navigation that has 3 levels
• In header -> apply "Mega Menu" setting to menu type setting

Note: This PR shouldn't affect any other menu types or make any changes to menus that only have 1 or 2 levels.

Demo links

• Editor

Checklist

• Added PR summary for release notes
• Notified the help.shopify.com team about updates to theme settings (current contact: Kimli)
• Followed theme code principles
• Linted with Theme Check
• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility

[allylane]

Visually this works as expected. The only other thing we need to do is remove the animation from the mega menu opening which we could also include in this PR cc @danielvan

[tyleralsbury]

Visually this works as expected. The only other thing we need to do is remove the animation from the mega menu opening which we could also include in this PR cc @danielvan

Are we removing that animation entirely?

[danielvan]

Are we removing that animation entirely?

I was discussing this with @allylane, and both of us had different experiences when the animation triggered and when it didn't, as well as the transition animation. @tyleralsbury, are we able to remove the animation for now and revisit on a different PR once we have time set aside to work on it?

[tyleralsbury]

Are we removing that animation entirely?

I was discussing this with @allylane, and both of us had different experiences when the animation triggered and when it didn't, as well as the transition animation. @tyleralsbury, are we able to remove the animation for now and revisit on a different PR once we have time set aside to work on it?

I think it should be easy enough to remove. Will try now.

[tyleralsbury]

@danielvan @allylane Animation has been removed.

[ludoboludo]

The code seem to work as expected but not a huge fan of the new approach/tweaks.

I find that it was easier to read with the bold level2. It did look not as good when you had too many level2 without any level3 menu item in them but I don't think this approach is any better in those cases, things kinda look maybe connected maybe not:

So I'd say I'm more in favour of our current approach with bold text but if we're to keep this approach then the code looks good 👍

[ludoboludo]

I find this a little small 😬
From what i'm seeing on other websites, having a bold or different color level 2 seems like the most common use case (H&M, Quicksilver, Fao Schwarz, etc).

[melissaperreault]

Something is off here, from the original logic, they would be styled as L2s, not L3s when in presence of L2s and L3s

[tyleralsbury]

Just to be clear:

L3s that are alongside L2s should be styled like L2s when they have no children. Is that right?

---

Actually this makes no sense...

L2s that are alone should be styled like L2s that have children. I think that's what it should be, is that right?

[tyleralsbury]

Should be fixed. It was cause of the :not(:only-child) that I added to prevent unneeded margins. I split it into two selectors.

[LucasLacerdaUX]

I also find 1.2rem way too small. I've looked at other websites (H&M, Quicksilver, Fao Schwarz, Gap, Simons, Nordstrom) and they're all using minimum of 13px. This led me to test with 1.3rem and it looks so much more readable. 1.3rem would match our link sizes for product links, which I personally find at the limit of being easily readable.

1.2rem

1.3rem

It does lose some of the hierarchy, so I'm not sure if there's something we can do about it.

I don't have the strongest opinion here, but just sharing my personal point of view as a user (very subjective :P). I find it kinda hard to read menus in Dawn and Studios on desktop when using 1.2rem fonts, and I'd prefer having less distinction between the hierarchy levels than barely being able to read without having to zoom / get closer to the screen

---

Other themes @ 12px

[ludoboludo]

So should we be switching to 1.3rem here?

[ludoboludo]

Looks better now 👌

But I think maybe it could be a little less margin.

[melissaperreault]

I also think they can be the same value!

[melissaperreault]

Ok, I am adjusting my opinion here! 😅

The gap between the 2 groups needs to be slightly different just to help identify when it is a start of a new topic in the same column. Otherwise we'll lose the connection we are trying to make between the L2 and the L3s with the white space, to convey they are closely related, the empty space is helping with that. I wouldn't want buyers to confuse them.

So my recommendation is to adjust a little bit more the spacing though to help this distinction! (Unless there is something I haven't catch! 🤔 ):

• margin-bottom: 0.8rem; instead of 1rem
• Keep gap at 2.4rem

Outcome

• Before
• After

[melissaperreault]

The code seem to work as expected but not a huge fan of the new approach/tweaks.

@ludoboludo I hear you and happy to share the context a bit! We've been bouncing back and forth for that one based on exploration test that bold wasn't scaling well for all fonts. We explored whether to keep bold or not and tested various outcome: Underline, Opacity, Uppercase, Divider columns, Bold and Size change, etc.

From the feedback we received, changing the size was the less opinionated styling we could go with until we provide better alternative to create hierarchy controls for merchants. But in the end, yes, indeed it's quite a subjective change!

[melissaperreault]

Thank you Tyler!

I've stress tested:

• Long menu names
• Tall menu list
• Uneven menu items
• Ipad
• Android
• Various fonts

Observations

Capturing here but will open a new issue for them if they don't exist yet!

• Long menu label overlap with the next column
• When menu list becomes long, combined with scroll, the experience is annoying, the mega menu closes on users pretty drastically. (Video reference)
• Scrolling inside the mega nav doesn't prevent from scrolling the page behind. This could convey there are still menu items to discover but in theory there are not. (Video reference)
• Mobile drawer nested back link label is centered instead of left aligned. Noticeable when menu text link is very long.

Other than that, very close to approve! Haven't found anything else! 🙏

[LucasLacerdaUX]

I'm not a big fan of the new 1.2rem font size (see comment) but code looks good and things are working as expected. If we're okay with the design, consider this an approval :D

🎩
✅ 👍
👖

[tyleralsbury]

Long menu label overlap with the next column

Fixed.

When menu list becomes long, combined with scroll, the experience is annoying, the mega menu closes on users pretty drastically. (Video reference)

Scrolling inside the mega nav doesn't prevent from scrolling the page behind. This could convey there are still menu items to discover but in theory there are not. (Video reference)

Blocked scrolling when the menu is open. This fixes both of these points.

Mobile drawer nested back link label is centered instead of left aligned. Noticeable when menu text link is very long.

Fixed.

I also adjusted the margin-bottom to 0.8rem.

[tyleralsbury]

@melissaperreault Not sure if we want to revisit the use of 1.2rem and switch it to 1.3rem. We could bump the L2s to 1.5rem if we did that to keep it 0.2 larger. I don't have a strong opinion.

Lucas's comment is a great exploration.

[ludoboludo]

this class, when applied and not only in this scenario, is creating a bit of a jump that makes the experience feel subpar 🤔

It does it as well on the drawer for pick up availability and probably anytime we apply the overflow-hidden class in the theme.

video

[ludoboludo]

When applying the overflow: hidden; it hides the scroll bar from the page so it creates that shift.

[tyleralsbury]

It's a bit tricky because different OS will have different treatments for this. Gut says something like add a margin/padding on the right side of the container to simulate the space the scrollbar was taking up, but that'll differ from browser to browser and os to os, so it'll never be perfect.

I think it's something we need to explore, but will take some time to find a good solution for.

[tyleralsbury]

One option that pops into my head but which I'm not sure would work... overflow-y: scroll might force a scrollbar (again, might depend on OS), and then make the height of the container 100vh so that it has nowhere to go... you'd also need to add a transform to it to position it in the spot it was in before adding the overflow. Feels complicated, but something like that might work. 🤷

We can look into if there are any more elegant solutions.

[ludoboludo]

Hmm yeah I was reading suggestions yesterday but nothing seemed very good or straight forward 🤔
This sounded interesting but didn't try it yet: https://aykevl.nl/2014/09/fix-jumping-scrollbar

[ludoboludo]

There is also one alternative that would be using this CSS property but it's not supported on Safari: https://ishadeed.com/article/prevent-scroll-chaining-overscroll-behavior/

So it would apply on the mega menu when there is an overflow and prevent the page to scroll when you reach the bottom of the mega menu content.

[LucasLacerdaUX]

Do we really need this overflow-hidden class? I believe that this worsens the user experience for EVERY mega menu only to fix an edge case (very long menus).

If this attribute was added only to fix the bug with long mega menus being randomly dismissed, it is caused by this auto-hide on the onScroll() event on header.liquid:

      if (scrollTop > this.currentScrollTop && scrollTop > this.headerBounds.bottom) {
        requestAnimationFrame(this.hide.bind(this));

We could add a check there to see if mega menu is open and prevent this auto-hide behaviour if it is. I think it's a much better solution.

Also, this oveflow: hidden solution isn't something we see in pretty much any website that uses Mega Menu (sure, they can control the menu height, but you still get taller than 100vh menus that works). So this pattern that mega menu open = scroll blocked isn't really a thing buyers are used to.

On touch devices, this becomes an even bigger problem because you don't even see the scrollbar disappearing, so what happens is that you open the menu and get trapped for no visible reason:

Screen_Recording_20220331-112651_Chrome.mp4

Can we revert this and fix it by preventing auto-hide in header.liquid instead?

[LucasLacerdaUX]

Follow up on the above:

Solution 1 (current)

Adding a overflow: hidden to body when opening megamenu.

Video

31-27-i30rj-p0icp.mp4

Cons

• Blocks scrolling when any megamenu is open ,regardless of its height.
  • In touch devices, users aren't even able to tell that the scrollbar is gone.
• Creates jumping on desktop.

Solution 2 (proposed)

Prevent header auto-hide on header.liquid by adding something like this (maybe we should cache this element and check if its open):

        if (this.querySelectorAll('.mega-menu[open]')) return;

inside this if block:

      if (scrollTop > this.currentScrollTop && scrollTop > this.headerBounds.bottom) {
        requestAnimationFrame(this.hide.bind(this));

and removing max-height: calc(100vh - var(--header-bottom-position-desktop, 20rem) - 4rem); from .mega-menu__content.

Video

31-26-s747a-u1he0.mp4

Cons

• Mega menu stays open until the user closes it, either by clicking the menu again or by clicking outside of it to dismiss.
  • Future enhancement: If we want, it should be possible to want to add a specific onScroll event as a future enhancement to autoClose once they scrolled past the megamenu.

[melissaperreault]

Thanks Tyler! Looks good to me! 🚢

Related to font size, I hear the feedback, we'll monitor and adjust later as we explore font hierarchy.

[danielvan]

I agree with the comments above on the L3s feeling small. I would be ok in shipping with 1.3rem for L3 to see if the comment repeats once this is live and in dynamic contexts. It seems also a gain for a11y and click target areas.

@melissaperreault ultimately this is a decision on the design system, so keen to hear your thoughts.

[LucasLacerdaUX]

Everything works and looks as expected. I'm okay to go with 12px for now and revisit font sizes later once we have better ways to enforce this hierarchy distinction.

However, the new overflow: hidden creates such a confusing user experience that I believe we should revert this fix before we merge. Left a comment below explaining why.

[LucasLacerdaUX]

Do we really need this overflow-hidden class? I believe that this worsens the user experience for EVERY mega menu only to fix an edge case (very long menus).

If this attribute was added only to fix the bug with long mega menus being randomly dismissed, it is caused by this auto-hide on the onScroll() event on header.liquid:

      if (scrollTop > this.currentScrollTop && scrollTop > this.headerBounds.bottom) {
        requestAnimationFrame(this.hide.bind(this));

We could add a check there to see if mega menu is open and prevent this auto-hide behaviour if it is. I think it's a much better solution.

Also, this oveflow: hidden solution isn't something we see in pretty much any website that uses Mega Menu (sure, they can control the menu height, but you still get taller than 100vh menus that works). So this pattern that mega menu open = scroll blocked isn't really a thing buyers are used to.

On touch devices, this becomes an even bigger problem because you don't even see the scrollbar disappearing, so what happens is that you open the menu and get trapped for no visible reason:

Screen_Recording_20220331-112651_Chrome.mp4

Can we revert this and fix it by preventing auto-hide in header.liquid instead?

[melissaperreault]

@danielvan

No strong opinion apart from following accessible recommendations to aim for bigger all the time on my end! We can ship with a 1px difference and monitor, instead of the 2px difference proposed during feedback time.

Less risk for merchants and buyers to go from 1.3 to 1.2 instead of the opposite. I'd also rather offer a bigger font size if we are aligned! cc. @nicklepine

[tyleralsbury]

For @LucasLacerdaUX 's comment, I'd like to defer to @melissaperreault. My logic for blocking scroll is that the rest of the page can't be interacted with anyway before the menu is closed, so you are somewhat in a modal or drawer-like context. So it made sense to me to treat it similarly to a modal or drawer.

[LucasLacerdaUX]

Just to add to my comment above:

[LucasLacerdaUX]

Follow up on the above:

Solution 1 (current)

Adding a overflow: hidden to body when opening megamenu.

Video

31-27-i30rj-p0icp.mp4

Cons

• Blocks scrolling when any megamenu is open ,regardless of its height.
  • In touch devices, users aren't even able to tell that the scrollbar is gone.
• Creates jumping on desktop.

Solution 2 (proposed)

Prevent header auto-hide on header.liquid by adding something like this (maybe we should cache this element and check if its open):

        if (this.querySelectorAll('.mega-menu[open]')) return;

inside this if block:

      if (scrollTop > this.currentScrollTop && scrollTop > this.headerBounds.bottom) {
        requestAnimationFrame(this.hide.bind(this));

and removing max-height: calc(100vh - var(--header-bottom-position-desktop, 20rem) - 4rem); from .mega-menu__content.

Video

31-26-s747a-u1he0.mp4

Cons

• Mega menu stays open until the user closes it, either by clicking the menu again or by clicking outside of it to dismiss.
  • Future enhancement: If we want, it should be possible to want to add a specific onScroll event as a future enhancement to autoClose once they scrolled past the megamenu.

[melissaperreault]

So this pattern that mega menu open = scroll blocked isn't really a thing buyers are used to.

Aligned, not the desired outcome I think, thanks for sharing this angle Lucas! We can park the use case/edge case and monitor because the point you are making is reallly not what we would want to refrain buyers to do! I'll open an issue!

I don't know how this can be improved but Mega menu are meant for large inventory that encourages long menu list. That following reference was difficult to experience considering these factors. Maybe we are pushing the edge cases a little too hard here but worth the conversation.

Scrolling inside the mega nav doesn't prevent from scrolling the page behind. This could convey there are still menu items to discover but in theory there are not. (Video reference)

[tyleralsbury]

So this pattern that mega menu open = scroll blocked isn't really a thing buyers are used to.

Aligned, not the desired outcome I think, thanks for sharing this angle Lucas! We can park the use case/edge case and monitor because the point you are making is reallly not what we would want to refrain buyers to do! I'll open an issue!

I don't know how this can be improved but Mega menu are meant for large inventory that encourages long menu list. That following reference was difficult to experience considering these factors. Maybe we are pushing the edge cases a little too hard here but worth the conversation.

Scrolling inside the mega nav doesn't prevent from scrolling the page behind. This could convey there are still menu items to discover but in theory there are not. (Video reference)

Sounds good. Lemme give Lucas's solution a try. If it works well, we can go with it.

[melissaperreault]

Solution 2 (proposed)

This seems like a good experience to rely on buyers to click outside the menu or a link to dismiss the mega nav and ensures it meets any inventory taxonomy length AND keep the ability to scroll if they wish. 👍

Again, I wonder what were the initial reason why this wasn't considered at first, why the menu nav was dismissing as you scroll out of the area. Might need to learn on past considerations too! 🙏

[LucasLacerdaUX]

Here's a prototype for my proposed solution:
https://os2-demo.myshopify.com/?preview_theme_id=127786778646
https://os2-demo.myshopify.com/admin/themes/127786778646/editor

[ludoboludo]

and removing max-height: calc(100vh - var(--header-bottom-position-desktop, 20rem) - 4rem); from .mega-menu__content.

I don't know if we should be removing this though 🤔 As your only way to close the menu would then to click back on the parent in the menu nav at the top. Having a gap at the bottom creates an opportunity for you to click and close the menu without having to go back to the menu nav and click on the parent.

[LucasLacerdaUX]

Made the changes. Took a slightly different approach to avoid unnecessary querySelectorAll on every scroll event, but the end result should be the same :)

[LucasLacerdaUX]

I've added this so the mega-menu is still scrollable when opened via sticky header.

Otherwise, we wouldn't be able to see the bottom elements due to the position: sticky.

Before:

31-05-iipgo-kavuc.mp4

After:

31-03-v0zlo-l1m9z.mp4

Does it address your concern above, @ludoboludo?

[ludoboludo]

It wasn't exactly my concern but good catch on that approach.

My concern was just that when the mega menu is taking the full space, the only way you can close it is by clicking somewhere in the header/the parent menu item.
And I know when I visit other website I sometimes tend to click somewhere else to dismiss a dropdown. But not a biggy 👍

[melissaperreault]

Yes! This is only when the mega menu will take the full height of the view space right - I am happy that we can click outside of the menu most of the time for mid range height menu

[ludoboludo]

It wasn't exactly my concern but good catch on that approach.

My concern was just that when the mega menu is taking the full space, the only way you can close it is by clicking somewhere in the header/the parent menu item.
And I know when I visit other website I sometimes tend to click somewhere else to dismiss a dropdown. But not a biggy 👍

[ludoboludo]

So should we be switching to 1.3rem here?

[melissaperreault]

Suggested change

	font-size: 1.2rem;
	font-size: 1.3rem;

To update based on UX recommendation to monitor and observe from different font perspective before decreasing the size smaller. Thanks! cc. @danielvan

[tyleralsbury]

Just made the commit - should be ready to test.

[melissaperreault]

Thank you team! Looks good! 🎉 🚢

[ludoboludo]

Seems good 👍

[ludoboludo]

One of the other effect, I say "issue" in the video but it isn't one. Is that the sticky header will stay stick until you close the submenu: video

But since it's easy to close I don't see it being too much of an issue 🤔 Just sharing so we know all the behavioural changes with this.

[LucasLacerdaUX]

👍🏻