Horizon Mega Menu: How the New Block System Handles Navigation

Merchants searching for a Horizon mega menu are looking for a setting that does not exist. A check of every navigation-related file in Shopify’s horizon repository at commit 8b42ace, dated 2026-08-31, turns up blocks/_header-menu.liquid with 18 settings and blocks/menu.liquid with 14 settings, and neither one contains the phrase mega menu anywhere in its schema. That absence is not a bug report. It is the actual shape of the theme, and understanding it means looking at what those two files do carry instead.

The menu block handles content, not layout

blocks/menu.liquid is built around a menu setting of type link_list, paired with a heading text field. From there its job is mostly about spacing and folding: menu_spacing is a range from 0 to 50 in steps of 1px, show_as_accordion is a checkbox, accordion_icon is a select with 2 variants, and accordion_dividers is another checkbox. Fourteen settings total, and every one of them either names the linked content or governs how it collapses on a small screen. There is no setting here that spreads a menu into columns or triggers a wide dropdown panel. If a merchant wants that look, this file alone cannot produce it.

blocks/_header-menu.liquid sits one layer up, in the header itself, and it carries more surface area at 18 settings. Alongside its own menu link_list setting it adds background_color and text_color, plus typography controls like type_font_primary_size with 5 variants and menu_font_style with 3 variants. That is styling depth, not structural depth. Coloring and sizing a menu item is not the same as arranging many menu items into a grid, and the schema confirms the theme keeps those concerns apart.

The wide layout comes from a generic block section

The actual mechanism for building something that looks like a mega menu lives in sections/_blocks.liquid, which is the largest of the four Horizon files checked here at 28 settings and 3 block types. Its relevant settings are layout primitives: content_direction as a select with 2 variants, vertical_on_mobile as a checkbox, horizontal_alignment as a select with 4 variants, vertical_alignment as a select with 3 variants, align_baseline as a checkbox, and a separate horizontal_alignment_flex_direction_column select with 3 variants for when the direction flips. None of these settings mention navigation by name. They are general-purpose arrangement controls that a theme builder can apply to a menu block just as easily as to a text block or an image block.

That means a wide navigation panel in Horizon is assembled, not toggled. A merchant combines the link_list from blocks/menu.liquid or blocks/_header-menu.liquid with the direction and alignment settings from sections/_blocks.liquid to get a multi-column dropdown. The carousel.liquid section, with 9 settings including columns as a range from 1 to 8 and columns_gap as a range from 0 to 100 in steps of 1px, shows the same pattern elsewhere in the theme: layout width and spacing are handled by dedicated layout sections, and content sections stay narrow in scope.

What this construction cannot do

Because the mega menu behavior is distributed across files rather than concentrated in one, there is no single switch that turns a standard menu into a wide one and no single setting that reports whether a given navigation block is currently rendering as a mega menu or as a plain list. A merchant auditing a live store has to check blocks/menu.liquid, blocks/_header-menu.liquid, and sections/_blocks.liquid together to understand what is actually being rendered. That also means any theme documentation or support answer that refers to “the mega menu setting” in Horizon is describing a combination, not a control, and treating it as one setting will lead to a search that turns up nothing, exactly as this search key does.

Comparing what Dawn does instead

Dawn, the older reference theme, organizes its comparable sections differently and the contrast is informative. sections/footer.liquid in Dawn has 12 settings and 5 block types, built around things like newsletter_enable, newsletter_heading as inline_richtext, enable_follow_on_shop, show_social, and enable_country_selector, all checkbox or text-style settings aimed at footer content rather than layout. sections/featured-product.liquid has 12 settings and 13 block types, centered on a single product reference plus display controls like media_size with 3 variants, constrain_to_viewport as a checkbox, and media_fit with 2 variants. Neither Dawn file resembles Horizon’s _blocks.liquid in scale or in the kind of alignment controls it exposes, which tells you the mega-menu-by-assembly approach is specific to Horizon’s newer block system and not a carryover from Dawn’s older section model.

Where performance fits into the decision

Adding more blocks to build a wide navigation layer is a real design tradeoff, even if the facts here cannot draw a straight line from menu complexity to load time on any specific store. The wider market gives a baseline worth knowing before making that tradeoff. Across 329 themes tracked in the aggregate ranking, checked 2026-09-04, the median price is $300 with a range of $100 to $500, and the average rating is 4.53 out of 5 across 308 rated themes with a median of 23 reviews. On performance specifically, mobile Core Web Vitals pass rates have a median of 85.5% across 247 themes with sufficient data, ranging from 46.1% to 98.6%, while desktop shows a median of 86.2% across 199 themes, ranging from 30.3% to 99.2%, all drawn from CrUX data covering July 2026 and reflecting real visitor traffic rather than a lab test.

What to actually check before building the layout

Read blocks/menu.liquid and blocks/_header-menu.liquid on the storefront being modified, list every one of the 14 and 18 settings on each, and confirm none of them is labeled for wide layout before assuming the theme handles it natively. Then look at sections/_blocks.liquid for the alignment and direction settings that actually produce the wide panel, and test the resulting page against Core Web Vitals data rather than assuming a heavier navigation layer will or will not pass.