Responsive Editing

Mortar Menu doesn’t support the traditional responsive method where Desktop Menu will be automatically transformed into a Mobile Menu at a certain breakpoint. Instead, you build a different menu for Mobile and decide when & where to show it with the Bricks’ Display control:

Why Mortar Menu doesn’t support the traditional responsive method?

After years of building navigation menus, below are what we have learned before deciding that.

The Pros of the traditional responsive method

1. Maybe save time

If Desktop Menu and Mobile Menu have the same content, it does save you some minutes of copying-and-pasting element. But if they doesn’t have the same content, the time to show/hide elements based on breakpoint might not save your time.

2. Less DOM output

Since a menu is rendered once, the DOM output is less than having two menus.

One thing people often misunderstand is that there are less HTTP requests as well. It’s not true. All modern browsers support HTTP caching. So two menus having the same content will do the same amount of HTTP requests as having one menu.

The Cons of the traditional responsive method

1. Not well supported by Bricks

Bricks builder doesn’t support an all-in-one element. It is against Bricks’ methodology.

You may think of the Nav (Nestable) element. It works because the Off-Canvas layout is simple.

2. Doesn’t work with advanced menu layouts

For advanced menu layouts, CSS and JavaScript alone can’t help transform a Desktop Menu into a Mobile Menu. The Paged layout for example. Sites such as Adidas and Nike still have to render two separate menus for Desktop and Mobile.

It’s possible to make it work. But, extra code to manipulate the DOM is risky for SEO and Accessibility.

3. Massive amount of controls will confuse users

If controls of both Mobile Menu and Desktop Menu are in one element, the amount of controls for all menu layouts will be massive for users to handle.