Add mega menu

[KaichenWang]

Why are these changes introduced?

Part of #947

What approach did you take?

Add Liquid markup for mega menu

• Leverage CSS grid to set 6 columns

Style links

• Currently in a snippet so it can be worked on in isolation, but can be moved into header.liquid
• Shares much of its markup structure with "dropdown" style desktop menu

Add header section setting for enabling mega menu

• Add setting in schema
• Add strings in en locale
• Use setting in Liquid to conditionally show dropdown or mega menu

Add styles for mega menu

• Add styles in component-mega-menu.css
• Styes added for menu container only (outer box; not the inside/contents)
• component-mega-menu.css is loaded only if mega menu is enabled

Other considerations

• Mega menu is WIP, do not merge into main

Testing steps/scenarios

• Editor settings (in header section)

Screenshot

• Toggle between regular dropdown and mega menu

Mega menu enabled

• Styling of menu container

Screenshot

• Test with all "Desktop logo position" setting options

Screenshot

• Test with global settings for Dropdowns and pop-ups

Screenshot

Demo links

• Store
• Editor

Checklist

• Followed theme code principles
• Linted with Theme Check
• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility

[KaichenWang]

Best to view diff with Hide whitespace enabled

[KaichenWang]

To confirm

Content - before requesting translations, I'd like to ensure copy is finalized and whether additional info copy should be added for merchants

cc: @katycobb

Screenshot

[KaichenWang]

To confirm

Design - a large logo combined with middle left logo position can cause a larger gap between the menu toggle and its contents. Is this a concern or an edge case that can be resolved by selecting a different logo position?

cc: @duygukalaycioglu

Screenshot

[KaichenWang]

To confirm

Design - Are there any particular tweaks to ensure cohesion with dropdown and pop-up global settings? For example, should the top corner-radius be hardcoded to zero? etc.

cc: @duygukalaycioglu

Screenshot

[bacounts]

The "desktop menu type" approach might be too limiting. I suggest keeping all the menus as "dropdowns" that can have a megamenu block added to them by menu item name. This will allow for people to mix-n-match menu types (dropdowns with megamenus and some single menus) and leave the possibility of coding a featured media block to a specific megamenu in the future.

[KaichenWang]

"dropdowns" that can have a megamenu block added to them by menu item name

@bacounts I like the idea of providing more flexibility. Could you elaborate a bit more on how that would look like in the theme editor to help me visualize your approach a bit better? Thanks

[bacounts]

@KaichenWang - Off the top of my head...

Editor Panel > "Header" section settings

• REVISE the "Desktop menu type" dropdown to show options resembling:

• Dropdown
• Mega menu
• Both

• ADD app blocks to the "Header" section (when either the "Mega menu or Both" menu type option is enabled).

• Add a block to a mega menu navigation item. In each block's settings you could assign a mega menu using a text field (ie. New Arrivals, case and cap sensitive).
• Assuming the mega menu is a flexbox grid with a max of 4 columns, blocks would be added after or behind the default "menu list," and stack like a grid. (Be sure to set a max-height to the overall mega menu container with scroll functionality).
• Allow a maximum block count of something high like 20 for each block type.

Some simple block examples could be:

• Featured media (image, heading, text, button)
• Product cards
• Article cards

Example: If our flexbox grid is 4 columns max, and you have one menu list (first column), you could have 3 or more Featured Media blocks after it to fill up the rest of the menu. This method could allow a user to have a mega menu of all featured media/blocks (when no sub-menu lists are present).

Let me know if this is making sense? Happy to elaborate more.

[gregjotau]

Please look into Baymard's recommendation on menu best practices when working with the mega menus, just some of the research:

Don’t Have Shallow Parent Categories:

However, at surprisingly many of the tested sites – and at 14% of e-commerce sites – the grouping of the drop-down categories were only text labels, not actual clickable parent categories. This conflicted with the expectations of the majority of the test subjects who anticipated the headers would be clickable.

[KaichenWang]

Editor Panel > "Header" section settings

• REVISE the "Desktop menu type" dropdown to show options resembling:

• Dropdown
• Mega menu
• Both

• ADD app blocks to the "Header" section (when either the "Mega menu or Both" menu type option is enabled).

• Add a block to a mega menu navigation item. In each block's settings you could assign a mega menu using a text field (ie. New Arrivals, case and cap sensitive).
• Assuming the mega menu is a flexbox grid with a max of 4 columns, blocks would be added after or behind the default "menu list," and stack like a grid. (Be sure to set a max-height to the overall mega menu container with scroll functionality).
• Allow a maximum block count of something high like 20 for each block type.

Some simple block examples could be:

• Featured media (image, heading, text, button)
• Product cards
• Article cards

Example: If our flexbox grid is 4 columns max, and you have one menu list (first column), you could have 3 or more Featured Media blocks after it to fill up the rest of the menu. This method could allow a user to have a mega menu of all featured media/blocks (when no sub-menu lists are present).

Let me know if this is making sense? Happy to elaborate more.

@bacounts Thanks for the clarification.

Providing merchants with additional flexibility in their menu layout and content is something we definitely want to add. However, the goal of this PR is to enable a relatively simple way for merchants to add mega menus to their storefronts; without requiring them to manage multiple blocks and menus in the header settings. I do foresee a need for blocks to allow merchants to add featured images, products, etc. to their menus, but this would be in a future follow up. Will be keeping your feedback in mind for those potential future iterations.

[KaichenWang]

Be sure to set a max-height to the overall mega menu container with scroll functionality

@bacounts noted!

[KaichenWang]

Please look into Baymard's recommendation on menu best practices when working with the mega menus, just some of the research:

Don’t Have Shallow Parent Categories:

However, at surprisingly many of the tested sites – and at 14% of e-commerce sites – the grouping of the drop-down categories were only text labels, not actual clickable parent categories. This conflicted with the expectations of the majority of the test subjects who anticipated the headers would be clickable.

@gregjotau Thanks for the insight. Is this an excerpt from https://baymard.com/blog/ecommerce-navigation-best-practice? Great information provided there; thanks for sharing!

For the mega menu in this PR, the sub-category titles are indeed links (not shallow).

[gregjotau]

Please look into Baymard's recommendation on menu best practices when working with the mega menus, just some of the research:
Don’t Have Shallow Parent Categories:
However, at surprisingly many of the tested sites – and at 14% of e-commerce sites – the grouping of the drop-down categories were only text labels, not actual clickable parent categories. This conflicted with the expectations of the majority of the test subjects who anticipated the headers would be clickable.

@gregjotau Thanks for the insight. Is this an excerpt from https://baymard.com/blog/ecommerce-navigation-best-practice? Great information provided there; thanks for sharing!

For the mega menu in this PR, the sub-category titles are indeed links (not shallow).

Yes, it is an excerpt from Baymard. Really recommend Shopify buy the premium subscription (not affiliated) and go through relevant guidelines and their research :)

Looking forward to the merge 🚀

[bacounts]

@KaichenWang — A final note: It could be worth looking into an "open" on mouseover function for the mega menu AND perhaps all menus on the navigation. This function could be added as a secondary toggled in the editor. I do not have exact stats around this, but most clients I have worked with prefer the menus opening on mouseover vs. click. I am sure there is also an Accessibility solution for both manners. I am looking forward to this merge.

[gregjotau]

@KaichenWang — A final note: It could be worth looking into an "open" on mouseover function for the mega menu AND perhaps all menus on the navigation. This function could be added as a secondary toggled in the editor. I do not have exact stats around this, but most clients I have worked with prefer the menus opening on mouseover vs. click. I am sure there is also an Accessibility solution for both manners. I am looking forward to this merge.

Have a hover delay of 300–500 MS if implementing that - tip from Baymard.

[duygukalaycioglu]

Thank you for sharing your thoughts and feedback, we really appreciate it! @gregjotau @bacounts

@KaichenWang already provided a great response regarding our upcoming improvement plans on mega menu, but to provide more context: Our priority at the moment is to give our merchants a second menu navigation option additional to the dropdown option. We chose the “click to open” interaction over “hover” because hover hasn’t passed the accessibility standards.

We encourage you to open a new issue to share your thoughts further.

[duygukalaycioglu]

Design - a large logo combined with middle left logo position can cause a larger gap between the menu toggle and its contents. Is this a concern or an edge case that can be resolved by selecting a different logo position?

@KaichenWang thanks for noticing this use case! I think it can be resolved by selecting a different logo position.

[katycobb]

To confirm

Content - before requesting translations, I'd like to ensure copy is finalized and whether additional info copy should be added for merchants

cc: @katycobb

Screenshot

Thanks @KaichenWang! I connected with D, we'd like to add help text below this field to let merchants know what to expect on mobile, since this is a desktop specific setting:
Dropdown is the default menu type on mobile.

Let me know if that makes sense/if you need any more info.

[KaichenWang]

@bacounts

I noticed a line to the left of the mobile menu container. It appears attached to the "transform: translate(0)" (see screenshot). To replicate, go to the mobile view in your theme editor.

I've created a separate issue to address this - #1463

I noticed that the top-level link does not remove the hover styling, and the link stays clickable when a "#" is used for the link field in the navigation editor. (See screenshot)

This isn't unexpected behaviour since I'm not performing any additional URL validation in Liquid and the default behaviour of the browser is to treat the <a href="#"> like any other link.

[ludoboludo]

Like @bacounts mentioned, there is a border to the left of the drawers on mobile. Not for the first levels but second and third which is coming from the declaration in .js .menu-drawer__submenu. Not sure if it was intended but doesn't seem to be introduced in this PR.

[ludoboludo]

Here as well, we apply a similar rule on:

list-menu__item--active:hover {
  text-decoration-thickness: 0.2rem;
}

Which maybe could be a common styling 🤔

[KaichenWang]

I agree this could benefit from some refactoring. The styles for menu links (dropdown + mega menu styles) are split between:

• .header__menu-item
• .header__menu-item:hover
• .header__menu-item span
• .header__menu-item:hover span
• .list-menu__item
• .list-menu__item--active
• .list-menu__item--active:hover
• .mega-menu__link
• .mega-menu__link:hover
• .mega-menu__link--active
• .mega-menu__link--active:hover
• .link

I'd like to consolidate this, but would prefer to do this in a follow-up PR at this point, because we'd have to make some changes in the markup of both menu styles and would have to re-test all use cases to ensure there are no regressions.

[ludoboludo]

💯 that makes more sense as a refactor follow-up/later.

[melissaperreault]

This isn't unexpected behaviour since I'm not performing any additional URL validation in Liquid and the default behaviour of the browser is to treat the <a href="#"> like any other link.

I think we need to reconsider this and validate with support advisor please 🙏

How can merchants create different hierarchy type where they don't have a link for a given header if we don't allow for "no link" menu item to create a structure? Buyers would observe this as a mistake from merchants store; the cursor change, I try to click the link but nothing happens. Forcing merchants to put a link on all menu items is really strange.

It's been a common request in the past, see example: https://community.shopify.com/c/shopify-design/drop-down-menu-without-link/m-p/320134/highlight/true#M83542

Perhaps an improvement to make at the platform level, I'll investigate further references.

[duygukalaycioglu]

I think we need to reconsider this and validate with support advisor please 🙏
How can merchants create different hierarchy type where they don't have a link for a given header if we don't allow for "no link" menu item to create a structure? Buyers would observe this as a mistake from merchants store; the cursor change, I try to click the link but nothing happens. Forcing merchants to put a link on all menu items is really strange.
It's been a common request in the past, see example: https://community.shopify.com/c/shopify-design/drop-down-menu-without-link/m-p/320134/highlight/true#M83542
Perhaps an improvement to make at the platform level, I'll investigate further references.

Thanks for your feedback @melissaperreault – much appreciated!
I agree that it is an improvement to make at the platform level.

I didn't know the "# hack" for headers with no link.

@KaichenWang
For the interim, if we can find a way to keep the bold weight for the headlines without a link – that would be great! If that is not possible, we can revisit during the platform improvement. @bacounts I'm taking a note to revisit the issue you brought up about the hover link, since it is a hack though I don't think we should expect it to work perfectly.

Apologies for editing and posting my comment multiple times, it took me some time fully understand what was being requested.

[KaichenWang]

Thanks for everyone's feedback regarding the use of # as link URLs. I'm happy to implement the special case if this can help merchants achieve a desired outcome and reduce support debt. However, just want us to make the best decisions so I will share my perspective:

1 - Obfuscation of the root cause of the issue - the Shopify admin should support navigation nodes with blank URLs. Continuing to handle this on the theme side, especially on Dawn, which should be a reference theme, could be interpreted as: we'd rather resort to hacks than implement the proper solution.

2 - Preserving 1-to-1 relationship between the data entered and what is displayed on the storefront is important. If # is entered as the url, the storefront should render the link as is without the theme making assumptions. Elsewhere in the theme, If a merchant enters # as a value in the editor (example: for a button link), Dawn renders the link href as is. I'm aware there are already exceptions to this - if L1 navigation nodes have children, we don't render them as links (URL is ignored), but I don't think this behaviour is ideal in all scenarios either.

[tyleralsbury]

2 - Preserving 1-to-1 relationship between the data entered and what is displayed on the storefront is important. If # is entered as the url, the storefront should render the link as is without the theme making assumptions. Elsewhere in the theme, If a merchant enters # as a value in the editor (example: for a button link), Dawn renders the link href as is. I'm aware there are already exceptions to this - if L1 navigation nodes have children, we don't render them as links (URL is ignored), but I don't think this behaviour is ideal in all scenarios either.

My 2 cents - this is the biggest reason not to do the # link. The merchant has input data and expects that data to emerge as-is on the storefront. If we manipulate their data, then you have a situation where the merchant can't be sure whether or not the data they add will be respected, and will question any data they add into the admin. It creates a theme level question of "will my data do what I asked it to do"?

[tyleralsbury]

@martinamarien

1 - Obfuscation of the root cause of the issue - the Shopify admin should support navigation nodes with blank URLs. Continuing to handle this on the theme side, especially on Dawn, which should be a reference theme, could be interpreted as: we'd rather resort to hacks than implement the proper solution.

@KaichenWang brings up a great point here. We should pick this up next week as well.

[melissaperreault]

My 2 cents - this is the biggest reason not to do the # link. The merchant has input data and expects that data to emerge as-is on the storefront. If we manipulate their data, then you have a situation where the merchant can't be sure whether or not the data they add will be respected, and will question any data they add into the admin. It creates a theme level question of "will my data do what I asked it to do"?

Yeah, I am totally aligned that this should be solved at the platform level! 💯 But in the meantime, there is no risk to support the hack as there is nothing else you would expect when entering # for your nav. Sharing below additional reasons why we need it until we have a better platform proposal:

• It’s a common online store advice https://help.shopify.com/en/manual/online-store/menus-and-links/drop-down-menus
• Already supported by other 3rd party themes
  • Third party theme examples:
    • https://help.outofthesandbox.com/hc/en-us/articles/115012624787-How-to-Make-a-Link-in-the-Main-Menu-Unclickable
    • https://www.youtube.com/watch?v=yjOeZuCk6mU
• Can help theme switching for existing nav including the # format
• Lowers the risk of support debt of merchants to request how to fix it

[martinamarien]

Thanks for updating Kai. I noticed a few things we will need to fix now that header-menu is being introduced. Let me know if you have any questions about what I commented.

[martinamarien]

I apologize I didn't see this earlier.
Currently, the --viewport-height is only assigned if the menu drawer is opened. So this will never be assigned a value on desktop if the customer doesn't resize their browser to mobile (and back to desktop).

[ludoboludo]

I wonder if it's a big deal anyway as we're using 100vh as a default if --viewport-height doesn't exist 🤔

[KaichenWang]

Updated to just rely on 100vh (which was the fallback/default) - 919a219

[martinamarien]

I am noticing an issue with the on-scroll for closing.
There are also a few places we probably want to take a look at that are applying styles for details-disclosure (base.css) or referencing details-disclosure in a script (cart notification + StickyHeader).

I think the issue with scrolling is being caused because StickyHeader is looking for details-disclosure. We could update both menus to use header-menu and that should solve that issue, alternatively, could query for both details-disclosure and header-menu.

[martinamarien]

The second issue I noticed is:
This is calculated on page load (Sticky on and off). This means that if someone scrolls down, and then re-loads the page, it will reload the page in the same position, and the header's position will be a negative value (e.g., --header-bottom-position-desktop:-2782px;). Since the max height is `100vh - --header-bottom-position-desktop), this will result in a value greater than the available space.

[KaichenWang]

There are also a few places we probably want to take a look at that are applying styles for details-disclosure (base.css) or referencing details-disclosure in a script (cart notification + StickyHeader).

I think the issue with scrolling is being caused because StickyHeader is looking for details-disclosure. We could update both menus to use header-menu and that should solve that issue, alternatively, could query for both details-disclosure and header-menu.

Updated 6efe289

This is calculated on page load (Sticky on and off). This means that if someone scrolls down, and then re-loads the page, it will reload the page in the same position, and the header's position will be a negative value (e.g., --header-bottom-position-desktop:-2782px;). Since the max height is `100vh - --header-bottom-position-desktop), this will result in a value greater than the available space.

Addressed this issue by setting --header-bottom-position-desktop inside onToggle() instead of in the constructor. The value may still need to be updated based on the state of the sticky header, but I haven't found a viable solution for that yet. For now, this should still work in preventing parts of the menu from being unreachable. 2ac6381

[ludoboludo]

Seems to work well for me this approach 👌

[vinxo]

Congratulations on the work done with the mega menu, I see that it has been added to the main branch but when I activate it in shopify the mega-menu block and the dropdown do not appear, am I doing something wrong or isn't merge yet? thanks in advance

[bredowmax]

Congratulations on the work done with the mega menu, I see that it has been added to the main branch but when I activate it in shopify the mega-menu block and the dropdown do not appear, am I doing something wrong or isn't merge yet? thanks in advance

I don’t see it merged yet into main. What did happen is that ‘add-mega-menu-content’ was merged into ‘add-mega-menu’

[ludoboludo]

It's working well 👍 Just have a question about the details-disclosure class now

[ludoboludo]

now that you've changed details-disclosure to header-menu I don't think you need to include it in here. Since from what I'm seeing this custom element isn't used anywhere now.

[martinamarien]

Same could be said for the css - if it's not used anymore.

[KaichenWang]

Correct, but if you remove these references, and details-disclosure were to be used directly in the future, you'd have unexpected behaviour. Removing these references would need to come with a warning: never use details-disclosure directly.

[ludoboludo]

Yeah it just feels a little odd to have some code for something that isn't used 🤔

Maybe we could have an issue to remind ourselves to check/refactor in the future based on its use cases ?

[KaichenWang]

Yeah i agree, maybe there's a better way to target details-disclosure and all elements that extend it at once.

[martinamarien]

Looks good to me Kai 👍🏻

[EconomicDecline]

Will aria-expanded be preserved or listed as an option for child and grandchild linklist items? Stores with linklists with many child options and subsequent grandchild options will end up with incredibly large menus otherwise

[KaichenWang]

@EconomicDecline

For the Mega menu, the answer is no. When each menu container is open, all child and grandchild links are meant to be visible and will therefore not require a aria-expanded attribute.

Alternatively, using the Dropdown menu style will allow lists of grandchildren links to be hidden/expanded (and will include an aria-expanded attribute).

Hope this answers your question.