/*****************************************************************************/
/* modified: 2005-06-08 /// (c) 2005 Jane Bond /// http://faq.bubax.net/     */
/* contact by mail: janebond at bubax.net /// http://janebond.bubax.net/     */
/*****************************************************************************/

/****** layout override for the slimmer JS hover menu ******/


/*** widths ***/
/*** header & navigation ***/
body #header #logo,
body #navigation {
  width:13em;
}

#header #switcher {
  width:13em;
}

/*** left margins ***/
/*** header & content ***/
html #header div {
  margin-left:13em;
}


html body #content {
  margin-left:13em;
}

/*** navigation ***/
html body #navigation {
  height:100%;
  padding:0;
  overflow:visible; /*
    This unfortunately removes the horizontal scroll bar in Opera 7.11 on Win98.
    But this browser was the only reason to introduce overflow:visible;
    otherwise the hover menu gets cut.
    These Problems now seem to exist in Opera 7.50/Linux also.
  */
}

/****** formatting the list entries for the JS hover menu ******/
html body #menu {
  position:absolute;
  z-index:1000;
  margin:0;
  padding:0.1em 0 0 0;
  top:12em;
  left:1em;
  background-color:#fff;
  color:inherit;
  width:12em;
}



/*******************************/
/* Mozilla hack session begins // 20050225  */
/*
   Since the hover menu fails over an element with overflow:auto
   in Firefox 0.9 and Mozilla 1.7, #navigation needs fixed
   positioning: It will be positioned with respect to the
   viewport, thereby resolving the bug.
*/
html>body #navigation {
  position:fixed;
  left:1%;
  top:0;
  width:12.9em;
}
html>body #navigation .w3cbutton {
  margin:2em 0 2em 0;
}
/*
   Unfortunately, the above workaround reveals another bug
   in Opera 7.5: Sometimes while scrolling the #menu and
   .w3cbutton gets hidden by the *html* element. position:fixed;
   resolves this bug.
*/
html>body #menu,
html>body #menu .w3cbutton {
  position:fixed;
}
/*
   Unfortunately, the above workaround reveals just another bug
   (or feature; I can't say)in Firefox 0.9 and Mozilla 1.7 again:
   The hover menu fails outside #navigation. Other browsers seems
   not to be affected. The descendant of root selector hack (Mozilla
   since 1.x, IE 5.x/Mac, Safari 1.x, Konqueror 3.3) may be useful
   here:
*/
:root body #menu,
:root body #menu .w3cbutton {
  position:absolute;
}

/*
   Still, in Konqueror 3.3 the same elements with overflow:auto do
   overlap the hover menu (this is not a problem with 3.1.5). This
   bug I can't solve. But since Konqueror 3.3 still imports this
   style sheet directly via JavaScript, these selectors have higher
   specificity; thus I can set the overflow property to visible again.
   This hack is dependent on the specificity of the JavaScript filter
   used!
*/
body>#content pre {
  overflow:visible;
}
/* Mozilla hack session ends   */
/*******************************/

html body #menu ul,
html body #menu li {
  margin:0;
  padding:0;
  list-style-type:none;
  background-color:#fff;
  color:inherit;
  border-style:none;
}

/* Tantek's hack */
html body #menu li {
  display:inline;
  voice-family: "\"}\"";
  voice-family:inherit;
  display:block;
}
html>body #menu li {
  voice-family:inherit;
  display:block;
}



html body #menu ul {
  width:12em;
}
html body #menu li {
  width:11.8em;
  position:relative;
}

html body #menu li ul {
  width:17em;
  margin:0;
  padding:0;
}
html body #menu li li {
  width:16.8em;
  margin:0;
}
html body #menu li li ul {
  width:18em;
}
html body #menu li li li {
  width:17.8em;
}

html body #menu, html body #menu ul {
  border:1px solid black;
}
html body #menu li {
  padding:0 0.1em 0.1em 0.1em;
}
html body #menu ul {
  position:absolute;
  margin:0;
  padding:0;
}
html body #menu li ul {
  visibility:hidden;
}

#menu li:hover ul {
  visibility:visible;
}

#menu li:hover ul ul {
  visibility:hidden;
}
#menu li li:hover ul {
  visibility:visible;
}




/* could be interesting for testing
#menu li:hover > ul {
  display:block;
  position:absolute;
  top:0em;
  left:13em;
  z-index:1000;
}
/**/


#menu li ul {
  position:absolute;
  left:12em;
  top:-0.1em
}
#menu li ul ul {
  left:17em;
}




html body #menu li a,
html body #menu li li a,
html body #menu li li li a {
  display:block;
  margin:0.1em;
  background-color:#d3e2ed;
  color:#292c63;
  padding:0.1em;
  font-weight:normal;
  text-decoration:none;
}

/*
  Following positioning of the first two list entries
  could be achieved through an extra class for IE, too.
  It is, by the way, by no means exact; that would be a
  16px+0.1em. But humans will notice this difference
  only at the very extreme of font sizing ;)
*/
html>body #menu li a {
  padding-right:16px;
}
#menu li+li+li a {
  padding-right:0.1em;
}
/* end of positioning-by-thumb */

html body #menu li a {
  padding-right:16px;
  text-align:right;
}
html body #menu li li a {
  text-align:left;
}
#menu li a.submenu {
  background-image:url(/images/arrowe.gif);
  background-repeat:no-repeat;
  background-position:right;
}

#menu[id = menu] li:hover>a {
  background-color:#309;
  background-color:#7daaca;
  color:#d3e2ed;
}
#menu[id=menu] li a:hover,
#menu li a:focus {
  background-color:#292c63;
  background-color:#7daaca;
  color:#d3e2ed;
}


/*** accesskeys ***/
#menu a[accesskey]::after {
  display:none;
}

/*** W3C buttons ***/

html body #menu .w3cbutton {
  position:absolute;
  bottom:0;
  z-index:90;
  left:0.76em;
}

/* The following hack is for excluding Konqueror 3.1.5 from bottom:0.
   20050131
   It is only necessary if navigation's positioning ist not fixed
   20050302 */
/* First, the top value is hidden from IE, because IE is not capable of
   overriding this value later on. Additionally, bottom is reset to auto,
   although buggy Konqueror doesn't seem to be affected by this: *//*
html>body .w3cbutton {
  top:20em;
  bottom:auto;
}*/
/* Second, top:auto resets the faulty value and proper browsers get
   back the desired bottom:0 again. Konqueror 3 doesn't see this
   because of whitespaces: *//*
html body ul[class=w3cbutton] {
  top:auto;
  bottom:0;
}*/