Netscape DevEdge

Skip to: [content] [navigation]

Netscape DevEdge Redesign: CSS


When we decided to remake DevEdge as an example of the kind of standards-based authoring we recommend, it was obvious that CSS was going to play a major role in that effort. Part of this is likely because I know CSS pretty well, but the more basic truth is that it's nearly impossible to do accessible modern site design without using CSS. Thanks to the great strides in CSS support, this effort is no longer the minefield of years past. In fact, in the process of designing, we discovered that cross-browser CSS support was even better than even I had realized. In this article, I'll take a look at how we approached the design project, where our efforts led us, and where we ended up.

Document Structure

The basis of any advanced styling project is a strong document structure. This doesn't mean that we had to create structure for its own sake, but it was necessary to mark the various portions of the document with clearly identified labels. The document skeleton for every page on the site is:

 <div id="masthead">(site masthead)
  <div id="skipper">(skip-to links)</div>
  <form id="srch">search form</form>
 <div id="main">
  <div id="content">(main page content)</div>
  <div class="sidebar" id="textbar">(left-hand rail)</div>
  <div class="sidebar" id="linkbar">(right-hand rail)</div>
  <div id="navbar">(navigation links)</div>
  <div id="nde-config">(configuration panel)</div>
 <div id="nde-footer">(site footer)</div>

This allows for the placement of various pieces of the document as desired. The document's source is also ordered with the idea that content comes after the site masthead, and ancillary content (links, navigation, et cetera) comes afterward.

This created the problem that the site navigation would be difficult to access in a screen reader, which would be forced to process the entire page content before reaching the navigation div. However, changing the document source so that the navigation links come before the content would mean readers would be forced to process the links before reaching the content. Either way, there would be a need to skip over unwanted information to reach wanted information.

Given this fact, we decided to put the content before navigation and other ancillary content. This means that in browsers that don't understand the CSS we're using, the document will begin with the masthead and search form, and then immediately goes to the content. The "skip link" to the navigation allows such user agents to skip over the content if they desire.

Styling the Skeleton

With the document's structure in place, we were ready to style. The first step was to set up the layout skeleton. In this design approach, the basic layout and text sizing of the site is established in one external stylesheet, while the colors of text, backgrounds, and borders are directed from another external stylesheet.

By taking this approach, it was possible to take an example document and use it as the basis of wireframe experiments in document layout. I chose the Viewsource article "Images, Tables, and Mysterious Gaps" because it was fairly lengthy, had multiple sections, and contained a number of graphic images and code blocks. This was a varied enough content sample to provide a good basis for the layout experiments. By adding a few borders to the pieces of the document and writing some simple positioning rules, it was possible to test out a variety of arrangements in rapid succession.

For example, the original redesign mirrored the old design by placing the site navigation links down the left side of the page. When it was decided we wanted a horizontal navigation bar across the top of the page instead, five minutes of CSS adjustments yielded a new layout wireframe for the team to consider. Adjustments to the placement of the configuration and search boxes, the typographic effects applied to the masthead, the spacing of the right-rail content, and other changes were similarly quick and simple. In many cases, it was possible to make layout changes during design meetings and preview the proposed layout changes immediately.

In the end, we settled on the basic layout you see on the site. If you're viewing the site in a Gecko-based browser, you can see the wireframe by opening the "Use style" entry in the "View" menu and selecting the "Basic Page Style" entry at the top of the submenu. (You can do the same in any other Web browser that allows you to use alternate stylesheets and the document's basic style.)

The basic approach to layout is to absolutely position the left and right columns, as well as the navigation link bar and configuration box, and leave the center (content) column in the normal flow of the document. The masthead is similarly left in the normal flow, but its descendent search box is absolutely positioned.

Why the mix of normal-flow and positioned elements? The positioning of things like the configuration panel and the navigation bar allow them to be placed in a visually adjacent manner even though the elements may be widely separated in the markup. In point of fact, whether or not they elements appear adjacent in the document source is irrelevant once you position them-- at that point, you can place them just about anywhere. The only thing to worry about at that point is whether or not positioned elements will overlap.

So at the end of it all, I had three basic elements in the normal flow of the document:

  1. The masthead
  2. The main content
  3. The footer

In addition, I had positioned the following pieces as described:

  1. The search box-- so that it overlaps the rightmost portion of the masthead
  2. The navigation bar-- along the bottom edge of the masthead
  3. The left column (when there is one)-- so that its top aligns with the top of the main content
  4. The right column-- with its top aligned with the top of the main content
  5. The configuration box-- slotted into the space between the top of the right rail and the navigation bar

With an appropriate mixture of positioning, height, and width values, the various pieces are fit together to create a consistent layout.

Filling In A Theme

With the wireframe layout in place, fleshing it out with colors was a simple matter of a separate stylesheet. The default style for the site is nde-blue.css, which defines the look of the "Gecko Blue" theme. It adds the color shadings to borders, text, and backgrounds of various layout elements.

For example, consider the basic layout styles for the configuration box (the box itself, not its contents), as found in nde-basic.css:

#nde-config {position: absolute; z-index: 50; top: 0; right: 0;
  width: 12.1em; height: 2.66em;
  padding: 0.66em 0 0; margin: -1px 0 0; 
  border: 1px solid; border-width: 1px 0;
  text-align: center;
  voice-family: "\"}\""; voice-family:inherit;
  height: 1.75em;}

This sets up the basic appearance of the box. Then, in the Gecko Blue stylesheet, we find:

#nde-config {background: rgb(17%,25%,50%);
  color: rgb(58%,60%,75%);
  border-color: rgb(11%,13%,34%);}

To change the colors of the configuration box for a nother theme, all that was required is the adjustment of the various values. Adding a background image would be a trivial matter of having the image and adding the needed value to the above rule.

Because the coloration styles are self-contained in a small stylesheet, creating new themes was quick and allowed us to try out various ideas quickly. One example is the "DevEdge Classic" theme, which was mocked up by another team member. Once I got hold of the background image for the masthead, I was able to fully re-create the look of his mockup in less than fifteen minutes. That includes the time needed to double-check color values for borders and other minor aspects of the coloration.

As we moved forward with our hybrid CSS/JS menu solution, we decided to take the basic menu styling and break it out into its own stylesheet. Over time, it evolved into three separate stylesheets:

By taking this approach, we were able to handle all of the menu presentation and layout via CSS, and use some simple JavaScript to make the menus appear and disappear as the user mouses over navigation links.

The entire navigation bar is itself a nested set of unordered lists within a containing div. Our starting point for this approach was the "pure CSS menus" demo, and was informed by work by Mark Newhouse and others. We considered at the outset using a CSS-only dropdown menu approach, but in the end decided that since (at the time) only browsers based on Mozilla 1.0 or later would be able to use the menus, it was better to add on just enough JavaScript to make the menus work. This opened up the range of browsers that would be able to use the menus to contemporary versions of Microsoft Internet Explorer and Opera.

In the original CSS-driven menu system, the dynamic behavior was driven by a creative use of :hover styles. In a browser that implements CSS2 well enough to allow hover styles for arbitrary elements, it is possible to create things like nested popup menus using nothing more than nested lists and some CSS. The basic technique is to hide the submenus, and then reveal them when a list item is hovered over. The basis of this technique is:

  ul ul {display: none;}
  li:hover > ul {display: block;}

Here, any unordered list nested within another list will be prevented from displaying. When a list item that contains an unordered list is hovered over, then the child list is set to display. By adding positioning and other styles, this can be used to create an almost infinite variety of menu styles.


We did our best to minimize the number of workarounds built into the new DevEdge site, but thanks to layout problems in various browsers, it was necessary to add in a few.

For example, thanks to disagreements between browsers over the width of elements, it was necessary to use the "Box Model Hack" to feed appropriate values to them. We saw an example of this earlier in the article:

#nde-config {position: absolute; z-index: 50; top: 0; right: 0;
  width: 12.1em; height: 2.66em;
  padding: 0.66em 0 0; margin: -1px 0 0; 
  border: 1px solid; border-width: 1px 0;
  text-align: center;
  voice-family: "\"}\""; voice-family:inherit;
  height: 1.75em;}

Because IE5.5/Win will subtract padding values from height, rather than adding them as defined in the CSS specification, it was necessary to feed it an inappropriately large value (2.66em) and then give other browsers the correct value. There are one or two other instances of such workarounds in the CSS. IE6/Win treats height (and width) correctly, and also sees the correct value at the end of the rule, so all's well that ends well.

The major workaround of the site was adding JavaScript to our menu code so that non-Gecko browsers could use them. While we would have liked to have stayed with a pure CSS menu system, in the end it was judged more important to create a menu system that worked for contemporary browsers that did not have the level of CSS support the menus required. Our JavaScript solution is really just a set of DOM calls that emulate what should be possible with CSS alone, and is discussed in more detail in Netscape DevEdge Redesign: JavaScript.

The Advantages

At the end of the process, we were left with a situation where every HTML document on the server could be styled by a relatively small collection of files. For pages such as articles or the Tech Centrals, an extra page-specific stylesheet could be used to add things to the site-wide stylesheet. The theme and menu files are also brought into play, as shown in the following diagram.

A diagram showing how the CSS, JavaScript, and HTML files work together

Although this may seem complicated, it's actually fairly simple. If you ignore the "theme" stylesheets and scripts, which are after all more optional frosting on the site, you're left with a primary stylesheet, a page-specific stylesheet (for example, styles specific to articles), a collection of files that drive the menu system, and an HTML document. Had we been able to rely on pure-CSS menus, several of those files could have been cut out.

By taking this approach, we were able not only to ensure consistency throughout the site, but also allow for language-specific styling. Simply by adding an extra stylesheet, elements can be resized to account for localized language differences, cultural expectations, or any other need that a localized file might have.


Thanks to the forward-thinking approach employed (and hard work invested) by the DevEdge team and the power of CSS, we were able to conceive, refine, and lauch a completely new site design in less than two months. Now that we have a strong structural foundation for our site, future design changes (or new themes) will be a simple matter of writing new stylesheets, and not having to worry about rewriting templates or restructuring our documents.

As we worked on the redesign, the ability to adjust layout with CSS was highly efficient and very helpful to the overall process, since we could test new layout ideas in close to real time. Once we had settled on a wireframe layout, adding in thematic colors and images was a near-trivial matter. (For most themes, it took longer to come up with a good masthead background image than it did to write the thematic CSS.)

Although we opted not to go with pure-CSS menus, our attempt to use them pushed us to create a solution that used as little JavaScript as possible and a method based on (again) structured markup. This meant we ended up with with a very lightweight cross-browser solution based heavily on CSS for its presentation. Although a few workarounds were necessary, they were actually quite minimal for an effort of this kind.

To be honest, even I was surprised by how much we were able to do with CSS in laying out the site design, and how few workarounds were required. We hope the results of our efforts will assist and even inspire you, and serve as one example of how sites can move forward to standards-based markup and design.