@Rich Melvin posted:A few points...
- The first line of defense with EVERY computer when it does something unexpected or different is to shut it down and reboot. About 90% of the time this will fix whatever was the problem.
- In this case, since it is related to a web site, the next action to take is to clear the cache and cookies in your web browser, then open the page again.
- There is no "CSS error" in play here. If you are seeing a different font on the "SEARCH" working, it is a browser issue. Here's what the top bar looks like on my machine in Firefox, Safari, and Internet Exploder:
Rich, I respectfully disagree. In your screen grab, the fonts are closer but on close inspection you can see the S, E, and R are different from from those in other places in the nav bar. It's evident also in the kerning.
Here are three screen grabs from my PC. One from FireFox, one from Chrome, and one from Edge.
As you can see, in each snip the SEARCH menu item has a font with serifs - different from that of the rest nav bar...
The reason this is happening is because of either a CSS error or possibly an issue with the a font library used for symbols like the "plus" and "bell" seen to the right of SEARCH.
The reason this is the case is follows:
As you can see, the anchor tag with in the last list item element has an idiomatic element that is using a FontAwesome class "fa-plus" which causes a plus to be shown in the nav menu to create new content. In the <li> tag above it, it's using fa-search with an aria-label (used by screen readers for those with a disability) of "Search". For whatever reason (CSS issue or issue in packaging the FontAwesome library) the browser can not find the the fa-search icon (should look like this: 
https://fontawesome.com/v4.7.0/icon/search) and instead defaults to showing the aria-label text. Defaulting like this will cause the browser to pick a default font. You might be on a Mac, Linux box, or an older Windows computer (I have no way of knowing) that is using a different set of default fonts that mine (and others).
The other problem with this is, is that this throws off the width calculation and then breaks the resize points, which is why this happens:
BTW, the wrap occurs at a window width of 1100 pixels!
Shrinking the width a little more yields the following with the collapsible sliding left menu:
I think this is likely also messing with the positioning of the pop-up box under "SEARCH" and calculating the overlay map for mouse movements. I can confirm that the disappearing search box that @Consolidated Leo mentioned happens for me too when the page is scrolled down from the top, and the window width is less than than 1144px. It also happens at higher widths depending on how fast I move my mouse.
