Child nav items not disapearing when trying to hover over them

Dear all, I am having some issues with a nav menu and specifically my child nav items not disapearing when trying to hover over them.

I think it has something to do with divs underneath the nav that are positioned with relative. I need relative positoning on these divs however, is there any way around this and what am I doing wrong?

My site with issues is here: http://kayana-fashions.com/collection/Kaftans you cannot select the second menu item as it disappears before you can move the mouse to it, whereas on other pages such as here http://kayana-fashions.com/press/ it is ok.

My menu CSS is below:

#nav ul#main-nav ul {
display: none;
}

#nav ul#main-nav li:hover > ul {
display: block;
}


#nav ul#main-nav {
list-style: none;
position: relative;
display: inline-table;
}

#nav ul#main-nav:after {
content: ""; clear: both; display: block;
}

#nav ul#main-nav li {
float: left;
}

#nav ul#main-nav li:hover {
background: #4b545f;
}
#nav ul#main-nav li:hover a {
}
		
#nav ul#main-nav li a {
display: block;
padding: 10px 40px;
text-decoration: none;
}
			
		
#nav ul#main-nav ul {
background: rgb(255,245,233);
padding: 0;
position: absolute;
top: 100%;

}

#nav ul#main-nav ul li {
float: none; 
border-top: 1px solid #6b727c;
border-bottom: 1px solid #575f6a;
position: relative;
}

#nav ul#main-nav ul li a {
padding: 10px 40px;
}	

#nav ul#main-nav ul li a:hover {
background: #4b545f;
}

Your slide show is stacking itself in front of drop down menu items.

add :

 #nav {position: relative; z-index: 2500;} 

hope that helps

Nice one :slight_smile:

#nav ul#main-nav {
list-style: none;
position: relative;
display: inline-table;
z-index: 2500;
}

Fixed it :slight_smile:

But now my question is, how did you diagnose that? Where can i see the z-index values? But i cant see this when inspecting elements in chrome there is no z-index listed on the computed values.

The z-index is not computed. it’s just a stacking order. Imagine an onion skin. The next sibling element stacks on top of the previous ( within the same z-index); tho this is moot as normally the next element also falls bellow the previous anyway.

Also most pre-made sliders /slider code rely on come CSS stacking tricks to show their images. so I just tested a large z-index number on #nav first, and voila.

Hi, d_p

Assigning {position:relative} without the z-index would have been sufficient. BIG z-indexes are kinda hokey. :slight_smile:

@dresden_phoenix :smiley: great!

@ronpat thanks also for replying - how does the relative positioning on the ul#main-nav work, does it assign some layering method other than z-index? In other words, so I can learn what is the CSS doing when using relative? :slight_smile:

The z-index property only applies to positioned elements (that is elements that are not position:static which is the default). Therefore for non positioned elements a relative position can be added (without co-ordinates) and not alter the position of the element.

As Dresden said non positioned elements are laid out in order of the html so if some overlap (with negative margins for instance) then those later in the html will be nearer the viewer (on top) than those earlier in the html.

To change the stacking order of non positioned elements you first need to give them a position:relative and then z-index will take effect and you can manipulate the stacking order as required. Note that if a child has a positioned parent and the parent’s z-index is not auto then that parent controls the stacking level for all its children and its children cannot inter weave with children outside of this stacking context.

When you apply position:relative to an element is automatically gets a z-index of auto (except in ie7 and under which give it a z-index of zero and thus confine all children to work in its prison). The fact that this element is positioned will automatically raise it above other non-positioned elements so a z-index would not be needed in some cases but to be sure you should set a z-index that satisfies the condition of the layout.

The explanations offered by dresden_phoenix were spot on. He explained that he arbitrarily chose a larger z-index number simply because some slider code uses z-index tricks to manipulate the slides. When testing your issue, I chose the opposite tack… I picked the smallest z-index number (none) and planned to add to it until I reached the minimum z-inded that would work. Turns out that the z-index of auto did the trick.

Why did I bother posting? Because you asked how the z-index value was calculated and I felt the need to put large z-index values into perspective; ie. bigger isn’t necessarily better, it’s just bigger.

There is a misconception that the z-index number conveys strength – a big z-index number is more powerful than a small z-index number – which is not accurate. It is a relative number that the browser uses to calculate the level (stacking order) at which the object should be placed on the page on the page.

The browser interprets or reduces the z-indexes to layers on the page.

On a page where there are no otherwise positioned elements, a single positioned element with a z-index of auto (no z-index declared), 1, or 2500 is one level above the non-positioned elements on the page.

The only useful reason for exaggerated z-index numbers is “coder’s convenience” when a page contains a large number of items with different layers that need to be manipulated.

…and Paul just posted a most technically accurate explanation. :slight_smile:

Perfect info from all who replied. Case closed - you guys ROCK! Thanks I really appreciate your help :slight_smile: