Pro tip: communicate to the client that shadows are a bonus feature. Your designers may disagree, but the site will not suffer considerably when special effects like box shadows, text shadows, or rounded corners are regarded as enhancements for decent browsers. However, your client’s budget will suffer when they are determined to provide the same visual effects on outdated browsers such as IE6. That said, here is the well-known method in CSS3:

1. .wrapper {
2. background-color: #fff;
3. border: 1px solid #d30d01;
4. box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
5. float: left;
6. height: 75px;
7. margin: 15px;
8. padding: 10px;
9. width: 75px;
10. -moz-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
11. -o-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
12. -webkit-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
13. }

1. <div class="wrapper">
2. <p>CSS box-shadow</p>
3. </div>

At the same time when we rolled out the website, Robert Nyman came to the conclusion that the proprietary Microsoft filter for Shadow looks much prettier than DropShadow, so I forgot about blogging myself as his solution doesn’t rely on unsemantic markup and is more elegant:

1. .wrapper {
2. /* For IE 8 */
3. -ms-filter: progid:DXImageTransform.Microsoft.Shadow( Strength=5, Direction=135, Color='#999999' );
4. /* For IE 5.5 – 7 */
5. filter: progid:DXImageTransform.Microsoft.Shadow( Strength=5, Direction=135, Color='#999999' );
6. }

Note that you get slightly better effects when you choose a dark gray instead of black as shadow color. If you can live with the rendering of the third box below, don’t read any further.

However, applying the filter had the side effect that text inside the box wasn’t anti-aliased in IE 6-8 anymore, and the shadow still didn’t look decent enough. So we added an extra span and applied the blur filter on it.

That led to a more complex code as we needed an inner wrapper where the border and background is applied to, while the outer wrapper merely acted as a … wrapper, where the styles were reset to defaults. HTML first:

1. <div class="wrapper ms-box-shadow">
2. <div class="inner">
3. <p>Internet Explorer with blur filter</p>
4. </div>
5. <span class="shadow"></span>
6. </div>

And here’s the CSS that’s added with Conditional Comments for IE 6-8 only (as IE9 supports native CSS box-shadow, more or less). The shadow element is absolutely positioned, set behind the inner content and blown up to 100%. Not original, but it works:

1. .wrapper, .inner {
2. background-color: #fff;
3. border: 1px solid #d30d01;
4. height: 75px;
5. padding: 10px;
6. position: relative;
7. width: 75px;
8. }
9. .wrapper {
10. float: left;
11. margin: 15px;
12. }
13. /* reset wrapper styles to defaults; work-around for screwed box-model */
14. .ms-box-shadow {
15. background-color: transparent;
16. border: 0 none;
17. height: 95px;
18. padding: 0;
19. width: 95px;
20. }
21. /* Move the inner wrapper to the foreground */
22. .inner {
23. z-index: 50;
24. }
25. /* The shadow element */
26. .shadow {
27. background-color: #000;
28. display: block;
29. filter: progid:DXImageTransform.Microsoft.Blur( makeShadow='true', pixelRadius=4, shadowOpacity=0.30 );
30. height: 100%;
31. left: 0;
32. position: absolute;
33. top: 0;
34. width: 100%;
35. z-index: 0;
36. }

For some reason I got a more similar result with the shadowOpacity set to 30% instead of 20%.

Where’s the crux?

If we are willing to ignore lots of bloated CSS: IE6 only blows the shadow up to 100% when the wrapper has a fixed height. This sucks, but unless you want to add more bloated code in JavaScript I don’t know of any solution for this problem. Still IE 7-8 handle a value of 100% right, and there are many cases where the height is known. Take for example photos where you’d like to apply shadows, some buttons, or horizontal shades lying above images, like the shadow of the second level navigation on this site. Beautiful, isn’t it?

1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?