MIT Interdisciplinary Consortium for Critical Infrastructure Cybersecurity

  • Welcome to (IC)<sup alt=3" /> Welcome to (IC)3
  • Panel at ARC Industry Forum Panel at ARC Industry Forum
  • MIT-(IC)<sup alt=3 at the ARC Industry Forum" /> MIT-(IC)3 at the ARC Industry Forum

How INDEX to move a sidebar menu to the top

Dreamweaver's layouts include the following comment under the sidebar menu: "If you would like the navigation along the top, simply move the ul to the top of the page and recreate the styling."

"Simply!" That's not a lot of instruction!

"Recreate the styling" is a very teasing way of saying "restyle the 'ul.nav' element."

Actually, with HTML5, rather than a "ul.nav" element (a "ul" element of the class ".nav"), it would be more modern to use a <nav> element and place the <ul> list inside it. Either approach should work with current browsers.

The CSS to restyle the menu is similar with either approach: The element selectors would be "ul.nav" the old way and "nav ul" the new way. Dreamweaver's HTML5 page layouts still use the "ul.nav" approach. (That is, a series of ".nav" class definitions in the stylesheet at the head of the document, and a <ul class="nav"> element in the body of the page.)

HTML5 TRANSITIONAL NOTE: Instructions in the latest edition of Adobe's Dreamweaver Classroom in a Book have users insert a new HTML5 <nav> element for a horizontal menu while still using "nav" as a class-name for the vertical menu elsewhere on the page.

Now that HTML5 allows <nav> as an element name, I'd suggest designers stop using .nav and #nav as class and ID names.

The same goes for making div names similar to the new HTML5 elements "header," "footer" and "aside." (Dreamweaver's new HTML5 layoutsuse those new elements, as well as "article" "address" and "section." They wrap "<aside>" in what looks like a redundant block, <div class="sidebar1">. Perhaps some browsers will need this double-coding. Or maybe some page designs would want to have more than one "aside" stacked together in a sidebar.)

Because students are using those original Dreamweaver-supplied layouts as a starting point, these instructions for moving the menu from sidebar to top use the original page layout's nav class attached to a ul list, and styled as "ul.nav {}" "ul.nav li {}" etc.

First step: MOVE your <ul class="nav">) block to be one of the first things in <div class="container">. It should work above the header, below the header, or inside the header -- as long as there is there are no inheritable padding or margin values applied to "header." If things look wrong, double-check the arithmetic of width, padding and margin to make sure one block still fits in another.

A <ul> list normally contains block-style <li> elements, each of which appears on a new line as a bulleted list. To make the list appear as a vertical menu, the Dreamweaver layout uses "list-style:none" to remove the bullets.

How do you get list items to not appear on new lines? You can do it the same way you get other elements of a page to appear side by side: add a "float" attribute to the <li> elements. If another page element comes after the list, and the list does not fill the whole page, remember to "clear" the float. (The Dreamweaver CSS stylesheets all include a ".clearfloat" class definition, which you can apply to the first non-floated element.)

You also should be able to line up the list items without "float" by adding "display:inline;" to the li {} style, according to this more general tutorial from However, either I've left out a step or something within the other coding of this page's Dreamweaver layout seems to keep the technique from working. (If you can tell me why, please do!)

Dreamweaver's layouts do not add "width," "color" or "background color" attributes to the <li> elements in menus; since the <li> elements only exist to contain anchor tag elements. The layout applies width, color and background to the <a> elements in all their states (link, visited, hover, active and focus). It groups "link" and "visited" together, which you might think of as "a link's native state," and it groups "hover, active and focus" together, which you might think of as "menu action" states.

Do the math: For a menu the full width of your page, add up the widths of the menu items (nav li a) including any borders or margins, and be sure they match the containing element. In this case that element is conveniently called "container." If you add a one-pixel border to the right of each [li a] element, be sure to add those pixels when calculating the width of container.

Four more ways of doing a horizontal menu:


Words appears inline and so do anchor <a> elements, so "Link One | Link Two | Link Three" with each link styled as an anchor is a perfectly acceptable horizontal menu. (Some use the &gt; > angle bracket to indicate a "breadcrumb" menu of pages in a hierarchy.)

As the Dreamweaver Classroom in a Book "GreenStart" exercise shows you, you can place that kind of menu in a <nav> element and apply styling to change the fonts and colors of the <nav> and <a> elements. The book has you put a <p> element within the <nav> element, possibly because some browsers may not recognize the new <nav> element. However, if you do that, remember that the <p> element has a bottom margin that you may have to zero out to avoid having a white band between the menu and the next element, as in the example below. (The silver backgrounds are applied to the nav elements.)

Unless you style the links, they will appear with the default settings for <a> elements anywhere on the page. Dreamweaver layouts style the <a> elements with subtle color changes in specific hexadecimal numbers, with underlining disapearing to indicate mouse actions; to make the code easier to read, I've edited the style sheet to make them blue (link), purple (visited) and red (active), the original Web link colors.


Dreamweaver includes javascript tools it calls "Spry" widgets, which embed a short script (program), some CSS, HTML and images, to create special effects. The "Spry menu" widget creates a horizontal or vertical menu with drop-down or fly-out submenus. Here's the default Spry menubar; the little triangles are gif files.

Unfortunately, if a phone, tablet or browser does not "support" javascript, the menu won't work. If you look at the sourcecode, you'll see the javascript added at the bottom of the page and some links in the head section.

Spry is easy to use from within Dreamweaver, but complicated to modify with other text editors. That's because the Spry widget isn't just a few lines of code in your page: If you look closely you will see that it installs a folder called "SpryAssets" containing a longer javascript, a css stylesheet, and four gif images. If you move a page with a Spry widget on it from outside Dreamweaver, be sure to move the SpryAssets folder too!

As CSS evolves and is supported by more browsers -- and more designers -- you will see more CSS-only menubars, including CSS tricks to handle drop-down menus without the embedded scripting and styling of Spry.


Many sites on the Web offer templates usiing non-Spry javascripts or CSS-only solutions to doing dropdown and flyout menus, sometimes relying on other javascript libraries, such as the popular JQuery. Some sites offer to sell or give away editable templates using such techniques, or provide online "wizards" to customize a menu for you. See, for example, a site called, which gives away some layouts for free and licenses others for a fee. Its layouts include new CSS features, including transitions, rounded corners, gradient background colors, and drop shadows.

Results can be impressive, such as this drop down menu using CSS's "shadow" attribute on the submenus.

Note:'s software is free for educational use, but labels the menu as created by


Finally, the most common technique for horizontal menus 10 years ago was to enclose the menu links in a table, using table rows <tr> and table datacells <td> to contain the menu items. Dreamweaver made creating tables much easier than manually writing HTML for them, and used them extensively in its original layouts, but the growing acceptance of CSS styling has made this technique unnecessary.

Table-style menu
Link1 Link2 Link3 Link4 link5

To learn more about the techniques used in the CSS Layouts supplied with Dreamweaver, read this article at Adobe's Developer Center -

Clearing Method Made Clearer

Here's another too-subtle instruction in the Dreamweaver layout comments. The page template advises you of the following:

Because all the columns are floated, this layout uses a clear:both declaration in the footer rule. This clearing technique forces the .container to understand where the columns end in order to show any borders or background colors you place on the .container. If your design requires you to remove the footer from the .container, you'll need to use a different clearing method. The most reliable will be to add a <br class="clearfloat" /> or <div class="clearfloat"></div> after your final floated column (but before the .container closes). This will have the same clearing effect.

However, the layout Dreamweaver supplies does not include that "clearfloat" class definition, so the code above would have no effect. Apparently the designers forgot, or they assume that all users understand CSS enough to add the class the the stylesheet. It would look like this: .clearfloat {clear:both;}

Sidebar background color

Dreamweaver's notes on this layout say:

By nature, the background color on any block element will only show for the length of the content. This means if you're using a background color or border to create the look of a side column, it won't extend all the way to the footer but will stop when the content ends. If the .content block will always contain more content, you can place a border on the .content block to divide it from the column.

So what if you want the sidebar to have a background color all the way down? One approach is to apply a darker background color to the whole div.container, and put a lighter background color in the article.content element. For some reason, Dreamweaver shows a band of the darker background color beneath the article.content element, but that does not apear in "Live" view or browser previews.