Clever smarty-pants catchphrase
Estimated @ 05.01.2008
This testcase makes use of many new CSS3 features. At time of writing Firefox 3β 2 displays the better result, followed by Safari 3, Firefox 2 and Opera 9.5β. Internet Explorer 7 will not give you a particulary good show.
Mocked up 03.01.2008
This page feature a variation a navigation bar with drop-down menus. Instead of multiple menus, which each drops down when activating the top menu item, it only has one large menu. The hypothesis is that one large menu is easier to navigate and getting an overview of the next possible link to click, as oppose to having multiple menus where you need to activate and investigate each top menu before you make a desision.
A single large menu like the one on this page will work best when each item in the columns are more or less evenly sized and as compact as possible. Otherwise you will end up with a mis-propotioned menu with too much empty space and an irregular layout.
<ul id="navigation">
<li>
<a href="#">Services</a>
<ul>
<li><a href="#">Webdesign</a></li>
<li><a href="#">Gadgets</a></li>
</ul>
</li>
…
</ul>
The markup is your plain old regular nested list. Nothing fancy going on here.
Same thing goes for the CSS.
It's all like with the convential multiple drop-down menu except for how it's
triggered. Normally you trigger the drop-down menu with a :hover
on the top-menu. (ul li:hover) To make them all drop just apply
the :hover to the root <ul> element. (Yes,
I'm aware that the :hover is normally added to
ul li a:hover since IE6
only support the pseudo-class for <a>. I just choose to
ignore it for this test case.)
#navigation ul
{
/* Hide sub-menu */
height: 0;
overflow: hidden;
}
#navigation:hover ul
{
/* Open sub-menu */
height: 6.8em;
}
Note that I didn't use display: none; and
display: block; to hide and show the menu. This is because
otherwise the top-menus won't inherit the sub-menu's width. (One interesting
observation when using the display property; Firefox2 doesn't
collapse the top-menus' width when the sub-menus are hidden again.) This is
why I used the height property in conjunction with
overflow to show and hide the menu.
So it's not a drastically different menu layout, but it's not something I've yet seen live on a site. There's plenty of the classic drop-down menu, emulating how the OS's does it. But is there a reason for it? Or is it just force of habit? Can merging the sub-menus give a better discovery experience for the users?
Scribbled on 05.01.2008
One of the more interesting
CSS3 features I came
across while playing with the layout was the :not()
negation pseudo-class.
A selector that allows for very powerful
CSS rules.
| Browser | Border Radius | RGBA | :not() | :first-child | :last-child | :target | ::after |
|---|---|---|---|---|---|---|---|
| Firefox3β 2 | Via -moz- |
Yes | Yes | Yes | Yes | Yes | Yes |
| Firefox2 | Via -moz- — buggy † |
No | Yes | Yes | Yes | Yes | Yes |
| Safari 3.0.4β (523.15) | Via -webkit- |
Yes | Yes | Yes | No | Yes | Yes |
| Safari 2.0.4 (419.3) | No | Yes | No | Yes | Yes | Yes | Buggy UTF-8 |
| Opera 9.5β (9770) | No | No | Yes | Yes | Yes | Yes | Yes |
| Opera 9.23 (8808) | No | No | No | Yes | No | No | No |
| Internet Explorer 7 ‡ | — | — | — | — | — | — | — |
* The Palatino type is only used for amperand symbols. Which is only present in the list of types used. —Yes, think of that one for a second. Did you notice what just happend there? ;) Chicken or the egg?
† Firefox2 doesn't anti-alias the rounded edges. And a bottom corner radius displaces the bottom edge by one pixel. As you can see on this page, the right most drop-down menu doesn't quite line up with it's left hand siblings.
‡ Internet Explorer 7 deviated so much, even where I wasn't using cutting edge CSS, that I desided to exclude it from my tests and wait for the Acid tripping IE8.