Managed navigation was introduced in SharePoint 2013 and it swept in a new way to manage your site navigation. No longer did you have to use your site structure, but now you could pick and choose sites/pages/list items/forms/etc. across your site and build out a custom navigation solution. You can mix and match and easily switch between the two. But as soon as you want to rebrand the navigation bar(s), you do need to have a plan in order to support both managed and structured navigation and code in response.

Scenarios Where You Need This Info

You are starting to set up your new SharePoint site and want to understand the code differences between managed and structured navigation before you start writing your CSS.
You have a SharePoint 2010 design you are converting over to SharePoint 2013/2016/SharePoint Online and plan to also switch to managed navigation.
You tried out one or the other and decided it doesn’t meet your needs and you are switching navigation setups.
You have one design that needs to be used for structured navigation sites and managed navigation sites. Only publishing sites support managed navigation.

Look Under the Covers at Structured vs. Managed Navigation

The HTML sent to your browser for structured navigation in SharePoint does differ from what it gets for managed navigation. This is what can lead to CSS incompatibilities when trying to use the same code for both styles of navigation.

Understanding why there is a difference in the HTML code is best displayed using visual diagrams.

Sample site collection

Below we have a sample site collection with a root site and child content in the form of sub sites, web pages and lists. SharePoint essentially treats each level separately, as we see with the “1”, “2” and “3” on the left side.

Site map — Diagram showing a sample site collection hierarchy.

Structured navigation display

Using settings from the master page, the SharePoint site will combine levels 1 and 2 into a single navigation bar and place level 3 as a fly-out/drop down menu. Structured navigation is all about what you have in your hierarchy is what you see in the user interface.

Structured navigation code

If you look at the generated code however, there is a bit of a quagmire. It makes sense… but it is tough on branding and CSS. The first level kicks off an unordered list (red below) with level two as a nested unordered list (green below). Each time there is a branch for level 3, that is another nested unordered list that is connected with the parent list item (blue below). Depending on the complexity of your site structure, your navigation code could have several nested lists.

Managed navigation

Using managed navigation in your site will allow you to cherry pick items to show in the navigation bar(s). This is especially useful if you have a really big site with lots of nested sub sites and content and don’t want to show all of your available content in the navigation. Below we have starred what content we want to show up in the navigation bar.

Managed navigation display and code

There is no need to break this into two different diagrams. Whatever content that you have selected becomes terms in the navigation term set. The levels and where the content is located in the hierarchy is irrelevant. Everything will appear as a simple and single unordered list (purple below). If you opt to add fly-out/drop down menus, those are added in as nested unordered lists attached to their corresponding parent (not displayed below). While that sounds similar to the nesting in structured navigation, this approach makes styling much simpler because it lacks level 1 (red colored root site in the above example) being a super parent list that wraps everything.

Code Differences

Luckily the code differences are straight forward and it is easy to switch your CSS back and forth to support one navigation system over the other or better yet, write CSS that supports both navigation systems. Your biggest ally in this process will be the child combinator in CSS, which is implemented with the greater-than symbol (>) in your code.

Key thing to remember when writing the CSS

When thinking about your CSS code for structured navigation, keep this image in mind:

If you write a style statement like this:

.ms-core-listMenu-horizontalBox ul li {
   border: 1px solid black;
}

With structured navigation you will affect the red nav item once, the green nav items twice and the blue navigation items (which would be in the drop down menu) three times. This is due to the nested nature of the three levels. Here is a visual example with the borders exaggerated so the effect is easily seen for the first two levels (red and green):

Here is the same code applied to managed navigation, without exaggerated borders:

Targeting navigation items

You actually can’t use the code listed above to create the single border affect displayed with managed navigation in structured navigation unless you change what you are targeting in the CSS selector. With structured navigation the parent list item for the top level site will forever wrap the children, so borders can’t be applied at the list item level. Instead you would need to go to a child element like the anchor (a) and then make the selector class heavy so you can override default SharePoint styles:

.ms-core-listMenu-horizontalBox ul.root li.static a {
   border: 1px solid black;
}

The nice thing about that style statement is it will work with either structured or managed navigation. The drawback is that it will also affect your drop down menu items. Depending on what you are doing, this may be a good or a bad thing.

To separately target the visible navigation items vs. the dynamic drop down menu items, you need to use the child combinator in your CSS selectors. Adding the child combinator (>) between the li and the a will only affect the visible navigation items:

.ms-core-listMenu-horizontalBox ul.root li.static > a {
   border: 1px solid black;
}

And to target the drop down menus you can do this:

.ms-core-listMenu-horizontalBox ul.dynamic li.dynamic a {
   border: 1px solid black;
}

Tips for branding the navigation systems

If you want to create code that is cross navigation system compatible, there are a few guidelines you can follow and a certain CSS practice you need to set aside:

Avoid referencing ul.static in your selectors – skipping this selector is a great way to encourage cross compatibility. Use ul.root for the visible navigation items and ul.dynamic for the drop downs.
Don’t skip referencing HTML in your selectors – it is a common practice with CSS to only reference the class in your selector. SharePoint navigation classes such as static and dynamic are shared across different HTML elements (ul, li, a) and using the .static class without a preceding ul, li or a can prevent cross compatibility.
Duplicate selectors for non-links – structured navigation gives you the ability to create linkless headers as a way to group custom links. These headers lack anchors in the code. You can be sure to catch any potential custom headers by duplicating your selectors and changing the a to span. For example:
```
.ms-core-listMenu-horizontalBox li.static > a.static,
.ms-core-listMenu-horizontalBox li.static > span.static
```