Login

UberMenu 3

Support CenterSubmit a Ticket

Custom Style Prefix / Specificity Booster

Overview

Residual Styling occurs when the theme adds styles that apply to UberMenu with high specificities that override UberMenu’s styles.

The Custom Style Prefix (Specificity Boost) setting allows you to regenerate the UberMenu stylesheets by adding a prefix of your choice to increase the specificity of the selectors and override the theme styles. (What is CSS Specificity?)

Generally, you’d set this value to the ID of the theme container.

UberMenu Custom Style Prefix (Specificity Boost)

Please note, specificity boosting is generally recommended as a last resort when a theme’s interfering styles are too messy to untangle through other means. CSS should be written precisely so that it doesn’t “leak” into other components and globally-applicable styles should be written with low enough specificity that they can easily be overridden by more specific styles. Using unnecessarily large specificities for CSS selectors can lead to difficulty maintaining a codebase and frustration for end users attempting to use multiple components that should be isolated from one another.

Specificity Example

In this example, UberMenu’s link text is set to red, but the text appears blue due to residual styling (overriding CSS) from the theme. This can be overcome with the Custom Style Prefix setting.

Let’s say that after integrating UberMenu, you end up with this markup, where the #theme-menu div is part of the theme:

<div id="theme-menu">
  <nav class="ubermenu">
    <ul class="ubermenu-nav">
      <li class="ubermenu-item">
        <a class="ubermenu-target">Home</a>
      </li>
    </ul>
  </nav>
</div>

UberMenu styles the anchor like this:

.ubermenu .ubermenu-target{
  color:red;
}

This selector has a specificity of 20 (2 classes).

The theme has a style like this:

#theme-menu li a{
  color:blue;
}

This selector has a specificity of 102 (1 ID, 2 elements).

Since the theme is using element selectors rather than classes as it should be in a modular system such as WordPress, this style still applies to UberMenu when it should not be.

Since the specificity of the theme’s selector is higher (102 > 20), the theme’s styles override UberMenu’s styles, and the link text appears blue.

This is “residual styling” from the theme.

One way to address this is to use a Custom Style Prefix. If we set the Custom Style Prefix setting to #theme-menu, then all of UberMenu’s styles get rewritten using this prefix. So now UberMenu’s style looks like this:

#theme-menu .ubermenu .ubermenu-target{
  color:red;
}

The specificity of this style is 120 (1 ID, 2 classes). Since 120 > 102, now UberMenu’s styles override the theme styles, and the link text is red.

Determining the proper prefix

Every theme is different. To determine the proper prefix, you’ll need to take a look at the theme markup surrounding the menu. In general, follow these principles:

1. The selector used must be an ancestor of .ubermenu

Remember, the prefix gets appended to all styles. You can’t use the ID on UberMenu itself, it must be an element that contains UberMenu.

2. Specificity of prefix should be large enough to override theme styles

This has to be taken on a case by case basis. Most of the time a single ID is the way to go. But say the theme is doing something strange like using #header #nav as its selector, you’ll need to make your prefix high enough specificity to override this.

3. Use the outermost container you can if you’re using multiple UberMenus

Remember that this prefix will apply to and replace ALL UberMenu styles. So if you’re using multiple UberMenus, make sure your prefix still selects all UberMenus on the page. If your prefix limits the styles to apply to a single UberMenu, then UberMenus outside of that container will be entirely unstyled. Therefore, use the outermost selector that will give you the specificity you need. Likewise, make sure the ID you use is present globally – not just on the page you’re currently inspecting.

For all of this, using your browser’s Developer Tools / Inspector is critical and makes the job easy.

Custom Style Prefix vs Manual Integration

Both the Custom Style Prefix and Manual Integration are potential solutions to the same problem: interfering styles from the theme that override UberMenu styles.

The Custom Style Prefix works by generating styles that override the theme’s styles, by using higher specificity CSS selectors.

Manual Integration works by eliminating the interfering styles from applying in the first place, by changing the site markup such that the theme’s CSS selectors no longer apply to UberMenu.

Which is better? In general, I think that manual integration is cleaner. I think it’s better to not apply unnecessary styles in the first place, than to apply them and then override them. But in practice, it’s likely not a big issue.

Here are the basic pros and cons of each option:

Manual Integration

Pros

  • Cleaner markup
  • Slight performance boost not applying extra styles
  • Almost always eliminates all residual styling interference
  • Also generally eliminates residual scripting

Cons

  • Requires a (child) theme code edit – the Residual Styling Detection / Manual Integration Tool can help
  • May affect other elements that the theme has injected into the nav
  • May need minor styling adaptations if the element replaced also controls layout positioning

Custom Style Prefix

Pros

  • Simple, no coding required

Cons

  • Still may not override everything – for example, if the theme uses CSS properties on items that UberMenu has not set, boosting the specificity won’t override that
  • Will not eliminate residual scripting (Javascript interference)

In the end, the best choice will depend on the specifics of your theme and your own capabilities. For *most* themes that cause residual styling, either option can work. While I would generally lean toward manual integration when possible, if you’re not sure how to approach that, the Specificity Boost is definitely a viable option.

It’s worth noting: This can all be avoided if the theme simply writes precise, properly componentized CSS styles. In the case of the WordPress menu system, this can be easily achieved either by using classes (.menu-item) rather than elements (li) in its selectors, or prefixing all of its selectors with an ID or class added via wp_nav_menu(), which UberMenu can then override. In other words, if coded properly, there’s no reason the theme’s styles should be applying to any menu other than its own in the first place.

On this page