raw output

CSS pop-up menus

By jacobo, on 2005-2-13 at 19:16, under Web dev

In Mozilla, Opera and Konqueror (and I suspect that in Safari too), this site uses pure CSS pop-up menus for its navigation bar. And they work very well, too (except that I had to use position: relative instead of position: absolute for the menus as Opera positioned them in strange places. A pity, I liked it better with absolute…).

These menus are implemented in the following way: first, the menu is defined in the HTML part using only the tags <ul> and <li:

<ul id="menu">
  <li>Links
    <ul>
      <li>Option 1</li>
      <li>Option 2</li>
      <li>Option 3</li>
    </ul>
  </li>
  <li>Whatever
    <ul>
      <li>Option 1</li>
      <li>Option 2</li>
    </ul>
  </li>
</ul>

Then, some CSS trickery is performed to have the <ul> blocks below a <li> tag invisible, with display: none; when the <li> has the mouse pointer on top, the <ul> changes to display: block:

#menu li ul {
  display: none;
  // other declarations to have nice squares instead of bulleted lists
}

#menu li:hover > ul { display: block }

And that’s it. I read about it in this page by Eric Meyer. And it works, indeed. And the contents of the menus are visible to people with text-mode browsers, too!

The only thing is, the inventors of the :hover CSS pseudoclass, Microsoft, only support a:hover in their terribly outdated browser; other things such as li:hover or img:hover are not supported. That means that the really nice trick above does not work.

And that’s where I enter, with some ideas from Quirks Mode (where I learned almost everything I know about the W3C DOM, and I have very much to learn yet) and this page by Peter Nederlof, where the author describes a method to “fix” IE to “accept” :hover for everything. Basically, the trick involves rewriting stylesheets on the fly to change the :hover pseudoclass into a real class, and adding some Javascript to have all elements change their class when the mouse pointer hovers on them.

I didn’t need such a generic solution, so I just picked the ideas and made my own scriptset. First, a custom stylesheet to be loaded by Internet Explorer only (done via IE’s conditional comments) and a script for changing classes of elements that are under the pointer. The stylesheet is similar to the original one, but instead of using the :hover pseudoclass, it uses the .fhover class; thanks to the script, when the mouse pointer moves on top of a <li> element inside the menu, its class is changed to fhover, and then back to “none” when the mouse pointer moves off the element. The effect is the desired one.

I also take advantage of the fact that IE does not support the CSS “>” selector, to make some styles invisible to IE.

Now it works, more or less. Submenus are not shown correctly, but I’ll eventually get around to fixing them: at least, they work now!

If someone has any ideas to fix them and make them look like they do in Mozilla, Opera or Konqueror, I’d be very happy if you posted them as comments or e-mailed me (my address is not hard to find via Google. Look at the page’s footer for my name).

Comments

There are 5 comments for this post.

  1. Comment by Benji_, on 2005-2-14 at 01:03 | permalink

    How many web sites will be derived from this technique? XD What about a “css cookbok"? It seems a nice idea: some solutions to visual and concrete web problems solved with css :) And CSS Zen Garden is not a good css cookbook example ;).

    Random note: Why this bizarre colours?! :P

  2. Comment by moebius, on 2005-2-14 at 02:28 | permalink

    Just to let you know: the cute menus work smoothly with Safari. They look great — apart from the somewhat strange colour scheme ;-). I think Apple made a great decision choosing an Open Source technology (KHTML) to make a web browser supporting W3C’s standards.

  3. Comment by Benji_, on 2005-2-14 at 10:45 | permalink

    Moebius: However they didn’t choose right open source technology: Gecko :P

  4. Comment by moebius, on 2005-2-14 at 12:33 | permalink

    No need to start a war of KHTML vs. Gecko, I think. Both are great pieces of software. Both render engines do a very good job when standards come to mind, but developers of both projects have different approaches when implementing new stuff… that’s why they are different and why both are neccessary, IMHO.

  5. Comment by Benji_, on 2005-2-14 at 12:59 | permalink

    Healthy wars are very good sometimes ;) I have this opinion based in some bad experiences with Konqueror (KHTML). Konqueror can’t render some pages that they can be rendered with Mozilla (Gecko). I want to believe that it is caused because KHTML is in early state of development than Gecko, IMHO too :).

Sorry, the comment form is closed at this time.