Navigation Widget style

nova20 · October 26, 2010, 10:55am

I’m trying to get a navigation that looks like this:

So, I’m using a horizontal rollover. I tried styling it like the help page says I should, but my css is ignored when I use the special classes (".sf menu" and “nav-level-2”). For now, my css looks like this:

div#barmenu {
	height:30px;

	text-align: center;
	font-weight: bold;
}

div#barmenu ul li {
	background-image: url("img/topbuttonbg.jpg");
}

div#barmenu ul li:first-child {
	background-image: url("img/topbuttonfirstbg.jpg");
}

…and my nav looks like this:

Here are the problems I’m having:
[ol]
[li]Somewhere, there’s a 1px white border defined that I can’t get rid of.
[/li][li]For some reason I can’t center the nav within the div.
[/li][li]Sub-menus don’t expand (horizontally) to accommodate longer names within the nav – for example, “Computing and Mathematics” wraps to two lines, which means my background repeats and looks like crap.
[/li][/ol]

I’d be perfectly happy to make sub-menus have just a color for the background, but I’ve failed doing that, too. Can someone help me out with a little css-fu?

vimrich · October 26, 2010, 11:54am

Lets go one by one:

The class name is “sf-menu” not “sf menu” (a dash, not a space). In your CSS theme, the selector should be .sf-menu … I’ll check to be sure the doc is correct here.

The one pixel border is coming from the sample CSS in the superfish.css file (this is also where that light blue color and other settings are when you first add the widget). The easiest way to suppress it is to add “border: none;” to every relevant class (there are more elegant ways using resets, but let’s start fast and simple).
Assuming the DIV is the region, and you want the Nav widget centered in that region, then what you are trying to do is center a block element (the DIV that is the nav) within another block element (the region DIV). The “text-align: center” and similar properties in CSS only center inline elements, like text, within the surrounding block element. To center a block element within another block element, you need to specify a width for the element (in this case, an overall width for the Nav widget element, then set margin-left and margin-right to “auto”.

Here’s an example CSS for centering the container (outermost) region, but the same css works for any other div you want to center:
http://help.percussion.com/cm1/Regions&structure=Percussion+CM1


          #container {
          width: 1000px;
          margin-left: auto;
          margin-right: auto;
          }

You could replace “#container” with a CSS class name that is on the DIV you want to center. Remember, you must set an overall width to center a block element in HTML (the width can be a percentage if you want it to be variable size). That’s not a CM1 thing, just a limitation of browsers and HTML centering period.

Roll-over expansion - in general - requires a fixed width for nav entry boxes. The reason is that the offset of the “next drop menu” has to exactly line up with the width of the prior level. Now, if you’re only using a single level of drop down, then you can suppress the width (set width to auto) and should will still work. You’ll need to tell the nav widget to only show the right number of levels of your nav in this case.

E.g. Suppose your nav is like this
Home (level 1)
About GSW, Admin, … (level 2)
Location, Mission Statement, … (level 3 under “About GSW”)
Directions, Facilities (level 4 under “Location”)

Set the nav widget to show levels 2 to 3 and you’ll have only one drop menu as a result. This first drop menu only has a vertical offset (it only expands downward) so you’re free to set the width to auto. You will need to set the height of the top level (level 2 of the overall nav) so that first drop menu doesn’t drop down too far (see below for more), but here the width can vary.

If you want that 4th level in the nav to be there and be expandable, then you have to fix the width of the third level, because the 4th level expands out to the right of the third level, by exactly the width of the 3rd level drop menu box.

Once you have some idea what’s possible given how many levels you want to have expandable, then you get to the question of how to set it. The best way is using .sf-menu combined with li and or ul.

I posted the BrightVovage theme here. Get it and copy the “navigation starts here” part of the CSS into your theme to start.

In BV, I pulled apart the CSS settings, and commented heavily on the size and offsets, and what and where height and width offsets need to match, and also some other things (like border-left set to none!). The BV “look” does not call for much of these drop menu effects, but the selectors in there still work at least as a better staring point. I can help you tweak it from there.

BTW, we’re writing up a whole new doc section just on how to style the nav.

Finally, you can still use background images and not solid colors for your top level and even the drop levels, but lets do one effect at time.

nova20 · October 26, 2010, 1:12pm

I must apologize in advance, guys. I’ve been in css hell for 5 hours now and I can be a bit snippy. Don’t take it personally – I’m frustrated at the design, not any of you.

That was a typo… I’m actually using “.sf-menu”, and actually it doesn’t look like that part is the problem, it’s the “nav-level-n” that doesn’t match.

Tried that – for perc-vertical, perc-widget, perc-navbar, sf-menu, perc-navbar-sfhorizontal, sf-js-enabled, and sf-shadow (all at the same time. The border persists. Am I leaving something out?
Tried that – I even thought I might have the margins defined on the wrong object… technically shouldn’t the margins be defined on the child of the outermost container? In any event, I’ve defined the width of the outermost container and defined margins there. Still no dice.

Wait, are you saying I should set the width and the margins on .perc-widget instead of on #barmenu? no, that didn’t work either. I know that’s the way it’s supposed to work, but it’s like something somewhere along the line is overwriting the automatic margins.

I’d rather have the extra levels there, and the word wrap doesn’t bother me. However, I’d like to be able to drop the background image for sub menu (nav-level-3 and higher) and just put in a color, which would solve the problem.

nova20 · October 26, 2010, 2:55pm

update:

I’ve removed the white border:

div#barmenu * {
	border: none;
}

Furthermore, I’ve been somewhat successful removing the background image when you drill down:

div#barmenu .sf-menu li li {
	background-image: none;
	background-color: navy;
}

…but like I said, only somewhat:

Anybody got any bright ideas?

vimrich · October 26, 2010, 4:16pm

This is raw, but I want to get it out there soon so you don’t have to wait for the formal doc. Here’s a quick PDF I put together that breaks down where and how to use CSS to style the Top Navigation widget. This shows pretty much all the possible variations you have - default, expanded and selected and each of these varying by level within the navigation.

Let me know if it helps. There’s probably bits of extra CSS I left out that help deal with older browsers, but you’ll see that in the BV sample theme I posted, and again, we’ll improve it as we go.

Hope the PDF helps: themeing-top-nav-in-cm1.pdf (269 KB)

vimrich · October 26, 2010, 4:24pm

The new classes we added for level, entry and position came out AFTER I did the original CSS theme. Those added classes are meant to deal with special cases like “the 4th entry of level 2 needs a special image that none of the others get.” Use the .sf-menu>li etc type construct to pick the level as shown in the PDF I just posted. The newer classes might work too, but I’m trying to reduce the variables here.

On your background image situation, it MAY be the case that “div#barmenu ul li:first-child” is considered more specific than “div#barmenu .sf-menu li li” So even if the second CSS bit comes after the first, the first one could still be winning. Do you still need the first-child selector?

However, it’s a background image. Browsers CACHE background images. So it could just be that you need to flush the browser cache. I beat my head against a wall for half a day once over that. CTRL-SHIFT-DEL in Firefox (not sure what it is in IE, usually just use the Options menu).

nova20 · October 26, 2010, 4:48pm

Thanks for the primer, Vern.

I solved my problem a slightly different way:

div#barmenu .sf-menu li {
	background-image: url("img/topbuttonbg.jpg");
	background-repeat: no-repeat;

	background-color: inherit;
}

div#barmenu .sf-menu li:first-child {
	background-image: none;
}

It seems like the “first-child” pseudo-class propogated to the submenus… so I took out the background image for that li.

I’ve found that when you use :hover, if you drop-down a menu and then move your mouse away from the menu entirely, you can see it change to the root menu style for a few seconds. I decided to leave out the :hover pseudo-class.

now I’ve got a completely different issue, and it seems like a weird bug. When I preview any page any deeper than level 3 in my navigation, some part of my nav is expanded. I’ve tried refreshing the page, but it stays there and I can’t get rid of it. Is this default behavior? How am I supposed to fix that?

vimrich · October 26, 2010, 5:04pm

Glad you’re working through stuff. I find sometimes that just the Nav can take a day (or just drop shadows or some other one tiny visual effect someone wanted takes a day), then the whole rest of the theme is a day or so for everything else.

I’ve started used “>” instead of space in nested selectors to help prevent unwanted propagation. Spaces match anywhere whereas “>” matches on that one direct level below. (but I usually forget and uses spaces out of habit and then have to go and suppress stuff again later, closer to what you did.)

Can you post a screen shot for those level 3 pages? I can’t quite tell what you’re seeing. Also, what version of CM1 are you using?

nova20 · October 26, 2010, 5:14pm

Sure. Here it is in firefox:

…and in IE:

I figure it’s possible I’ve got something screwy in my css. Here’s my custom code, which I tacked on to the end of perc_theme.css (after all the widget css):

/* (Begin) GSW customization */
/* 
	to fix:
		- anything right under a "hack" comment
		- this site looks like poop in IE < v7
		- replace borders with frackin' drop shadows.
*/

body {
	background-color: #f1f1f1;
	background-image: url("img/bg.jpg");
	background-repeat: repeat-x;

	padding-top: 0;
	margin-top: 0;
}

div#container {
	margin-left: auto;
	margin-right: auto;

	width: 1000px;
	overflow: hidden;
}

div#leftside {
	text-align: center;

	width: 232px;
}

div#logo {
	background-image: url("img/logo.jpg");
	background-repeat: no-repeat;

	width: 232px;
	height: 188px;
}

a#homelink {
	display:block;
	width: 232px;
	height: 188px;
	text-decoration: none;
}

div#nav {
	min-height: 50px;
}

div#nav a {
	color: navy;
	text-decoration: none;
	font-size: 14px;
}

div#nav ul {
	padding-left: 11px;
	padding-right: 11px;

	list-style-type: none;
}

div#nav ul li {
	width: 210px;
	height: 28px;

	line-height: 28px;

	background-image: url("img/menubutton.jpg");

	overflow: hidden;
}

div#nav ul li:first-child {
	background-image: url("img/menubuttonfirst.jpg");
}

div#nav ul li#last {
	height: 29px;

	line-height: 29px;

	background-image: url("img/menubuttonlast.jpg");
}

div#comlink {
}

div#notfooter {
}

div#middle {
	width: 760px;

	/* hack */
	/* perhaps there's a margin defined somewhere in the widgets */
	margin-top: -11px;
}

div#header {
	background-image: url("img/header.jpg");

	width: 768px;
	height: 168px;

	margin: 0;
	padding: 0;
}

div#header a {
	color: white;
	text-decoration: none;
}

div#search {
	height: 30px;

	padding-right: 15px;

	line-height: 30px;
	text-align: right;
	font-weight: bold;
}

div#title {
	height: 108px;

	overflow: hidden;

	text-align: center;
	color: white;
}

div#title h1:first-child {
	padding-top: 20px;
}

div#barmenu {
	height:30px;
	width: 768px;

	margin-right: auto;
	margin-left: auto;

	text-align: center;
	font-weight: bold;
}

div#barmenu * {
	border: none;
}

div#barmenu .sf-menu li {
	background-image: url("img/topbuttonbg.jpg");
	background-repeat: no-repeat;

	background-color: inherit;
}

div#barmenu .sf-menu li:first-child {
	background-image: none;
}

div#barmenu .sf-menu li li {
	background-image: none;
	background-color: navy;

	border-top: 1px solid white;
	border-left: 1px solid white;
}

div#barmenu .sf-menu li li:first-child {
	border-top: none;
}

div#content {
	padding: 5px 15px 5px 5px;
}

.shadow-right {
	/* to simulate the drop shadow...
	border-right: 5px solid grey; */

	-moz-box-shadow: 5px 0 5px #888;
	-webkit-box-shadow: 5px 0 5px #888;
	box-shadow: 5px 0 5px #888;
}

.shadow-bottom {
	/*to simulate the drop shadow...
	border-bottom: 5px solid grey;*/

	-moz-box-shadow: 0 5px 5px #888;
	-webkit-box-shadow: 0 5px 5px #888;
	box-shadow: 0 5px 5px #888;
}

.shadow-hack {
	/* for IE, because it's "special" */
	behavior: url(ie-css3.htc);
}

div#footer{
	text-align: center;
}

/* (End) GSW customization */

vimrich · October 26, 2010, 5:45pm

What page is that screen shot showing, in terms of the finder path? Is that for example:

sites/gsw/academics/test/index.htm

OR
sites/gsw/academics/test/some-other-lower-section/page.htm

It shouldn’t matter, but I’m just trying to figure out what is going on.

The menu should only show up when you hover because the there is a top offset of -999em. I can’t see anything in your CSS that overrides the “top:” property of a ul or otherwise gets in the way.

You mentioned earlier you got rid of an li:hover somewhere, you do need at least the li:hover that pulls the first drop menu down usually there is a CSS selector like this in the theme or the superfish.css that does it:


/*second level */	
.sf-menu li:hover ul,
.sf-menu li.sfHover ul {
	left:			0px;
	top:			30px;  /*match top ul list item height */
	z-index:		99;
}

That CSS modifies the top: offset from -999 to 30, which is relative to the other list so it shows up 30px (in the above case) below the first row of nav entries.

The .sfHover in the above works with the superfish.js to “smooth” the effect of going from -999 to 30.

I checked and there were some bugs we fixed prior to 1.3 that impacted nav behavior. What version of CM1 are you running?

nova20 · October 27, 2010, 9:17am

Sorry… I’m using v1.3.

It happens on any site deeper than /sites/gsw/ – any page on level 2 or deeper. The nav section for that page is expanded (if I click on “About GSW”, or any sub-items of “About GSW”, the “About GSW” menu stays expanded on the resulting page). The filename of the page doesn’t matter; it does it if I go to index.html or test2.html or whatever. I also don’t have to use the nav to get to that page – it happens when I simply preview the page from the CM1 dashboard.

I have found one thing, though. If “Academics” is expanded and I mouse-over a different item that has a sub-menu (like “About GSW”), the first expanded menu disappears and the second one sticks open.

I also notice that it does so if I use :hover or not referring to the sub-menus. I use:

div#barmenu .sf-menu>li li {

instead of:

div#barmenu .sf-menu>li:hover li {

…to style my sub-menus. Otherwise, if I mouse over the menus, then move my mouse away, the menus change style for the few seconds that it persists – at least in firefox it does.

Here I have my mouse over “Schools”, which is under “Academics”. Note that the sub-menu items have a navy background:

Here I’ve moved my mouse away from the menu entirely. Note how the sub-menu items change to the default light blue background:

The way I do it (without the :hover), the menu items keep the navy background until they fade away.

I’ve noticed that this weirdness doesn’t happen in IE, but the stuck menus problem does persist in IE.

vimrich · October 27, 2010, 11:19am

I may need to just put your theme into my demo system to see what is going on. Some things that could be in the way here:

li vs. a styles - the A (anchor) style is actually “in front” of the LI style and A styles can set bg color and other things too, so you might need something like this.


.sf-menu li li a, .sf-menu li li a:visited { /* second level display for "unselected" entry */
	color: #0c3b3d;
	font-size: 12px;
	}
	
.sf-menu li li a:focus, .sf-menu li li a:hover { /* second level display for "selected" entry */
	background:	#c6eb5c;
	color: #fffb61;
	}

The li:hover, when you do use it, should only ever come at the end. Also note there is a sfHover class added by the superfish.js as part of the dynamic drop effect. Could be that’s missing or being overridden. Here’s a typical example of that part (which is also consistent with the snippet of CSS above). (Yes, I’m using spaces here and not “>” between the LIs but that shouldn’t matter, and it’s just from the example I had.)


.sf-menu li:hover, .sf-menu li.sfHover {  /* top level display when entry is expanded */
	background:	transparent;
	}
	
.sf-menu li li:hover, .sf-menu li li.sfHover { /* second level display when entry is expanded */
	background:	#c6eb5c;
	color: #000000;
	border-top: none;
	border-left: none;
	}

nova20 · October 27, 2010, 11:51am

I actually set anchor styles within the region itself (#barmenu), and it seems to propagate well to the lower eschelons of menus.

I fixed the hover thing by just leaving it out – that way the all the list items look the same no matter where my mouse is.

What I’m worried about is the sticky menu bug.

vimrich · October 27, 2010, 1:41pm

The :hover class is what makes the menus appear and disappear though. The default offset for the second level and beyond menus is -999em (off the top of the page). Then the :hover class activates and the menu offset drops to, say 30px, so that it’s visible just 30px below the top menu bar.

You don’t have to use li:hover for other things, but you do need something like this in your CSS to manage the offsets:



/* first level */	
.sf-menu ul {
	position:		absolute;
	top:			-999em; /* do not change, keeps drop menu off screen until needed */
	width:			125px; /* left offset of submenus need to match (see below) */
}

/*second level */	
.sf-menu li:hover ul,
.sf-menu li.sfHover ul {
	left:			0px;
	top:			30px;  /*match top ul list item height */
	z-index:		99;
}

/* third level */
ul.sf-menu li li:hover ul,
ul.sf-menu li li.sfHover ul {
	left:			125px; /* match ul width */
	top:			0px;
}

Something in your CSS may be getting in the way of that “top:” offset causing the menu to appear before the mouse hovers over it.

vimrich · October 27, 2010, 2:17pm

Maybe I can hit your CM1 server from here? At this point I want to hit your pages with Firebug and see more specifics about what is going on. I’ve got a meeting coming up at 3pm EST, but maybe we can do a GoToMeeting later today or tomorrow? I doubt it’s a bug, but I can’t see enough from the fragments of CSS in this thread.

nova20 · October 27, 2010, 3:28pm

Tomorrow would be better for a webex.

As far as hitting our cm1 install from outside – that’s no easy task. VPN access is guarded closely, and any changes to the firewall require a lengthy change management process.

I’ve attached a .zip of my theme folder, which includes the .css and all the images I use. The only thing missing is the ie-css3.htc file, but I don’t think you need that.

vimrich · October 27, 2010, 4:33pm

No probs with the remote stuff - we have the same issue here. I’ll take a look based on the zip then let you know - might not be until later in the day tomorrow.

nova20 · October 28, 2010, 9:12am

No problem. I’ve got a meeting at 11:30 this morning, so I probably won’t be available until this afternoon anyway.

vimrich · October 28, 2010, 12:07pm

One of my colleagues got in ahead of me (thanks Bob!) and ran your CSS on his demo system this AM. It appears something is wrong with the Nav Widget. The sfHover class is being set on the LI of the current section - making the nav for the current section “stick open” as if being hovered. I submitted a Support issue on your behalf already and we’re looking into it.

There are some CSS workarounds to this but depending on your urgency, I think it makes sense for us to look at it more before just shutting off superfish.js or using CSS to hammer over the bad behavior.

BTW, the delay you are seeing is a feature of superfish.js menus which are hooked by default into the Nav Widget. All it really does is “smooth” the transition effects of the menu drops and hides so the menus do not “jitter” disruptively as the mouse moves and hovers. In this case, the smoothing seems to be too strong even in the parts that work, and the sub menus are hanging around way to long after the hover is removed. Once we fix the stickiness, we should be able to speed up the smoothing so the menu doesn’t appear to just hang there after the mouse is long gone. But this is just a timer setting. The stuck open menu thing is a different issue.

The sticky behavior seems to just be wrong based on what I saw. sfHover is only supposed to show on LIs that are being hovered.

As for the light blue look and feel “leaking” through, that’s easily corrected with a bit of CSS, but I want to hold off until we have the stickiness thing fixed.

vimrich · October 28, 2010, 5:26pm

There’s a definitely a bug here. We’re working through it now and will post or contact you when we have details.