I recently put together a custom theme for this blog. I wanted to take an idea from concept to completion to see what issues occur along the way. This involved designing, developing and testing the custom theme.

Design and Development Process

The problem with one person performing the role of designer, developer and tester on a single project is that concessions tend to be made with each role. It's well known that programmers should not be the ones to black box test their own code (I'm not talking about TDD here) because the test coverage will tend to be biased or subject to blind spots. If a developer is designing the visuals for the site, then he or she is probably going to restrict the creative process by over burdening the design with worries about the implementation phase.

Since I had to perform the role of designer, developer and tester for this project, I wanted to cleanly separate each role. This helped me keep the focus solely on each step as I progressed through the project, thereby avoiding the issues above.

To design the custom theme, I used Adobe Illustrator CS3. An alternative to this is Expression Design, which I'll be looking at soon. I used Visual Studio 2008 to write the CSS and code. Finally, I used a VM with several browsers installed to test the CSS.

Design Phase

I began the design by loading Illustrator CS3 with a new Web Document. Using the Rectangle Tool, I very quickly plotted out areas for the common features of a blog template, including a header, menu bar, side bar, content area and footer. I decided on a default color for each area in addition to setting up some gradients to jazz things up a little. Below is a screen grab showing the result of this step.

So far, the design is really simple. Regardless, at this point I'm not considering any CSS implications. I'm not asking myself, can this even be implemented with CSS? From a development point of view, this is not a good approach to take. But we're not in the development phase yet. We're only working on a design, and we don't want to restrict the design with implementation issues too soon.

With that in mind, I decided to complicate things a little. I wanted to make the side bar appear as though it's sitting on a translucent layer that exposes the area underneath it. This is very easy to implement in Illustrator CS3, but alarm bells started going off in my head. Is this going to cause me CSS headaches in the development phase? Quite possibly, but lets ignore that for now. We're still in the design phase.

The screen grab below shows the design with the new translucent side bar.

At this point I was happy with the first draft of the design. It's quite basic, but all of the required areas are in place and I've satisfied the designer in me with the translucent side bar.

Before proceeding to the development phase I briefly investigated my options with regard to implementing the design with CSS. I put together a strategy I knew would work with CSS. This involved breaking the design into a series of horizontal strips using divs and associating styles with these divs to recreate the design in the browser. Any problems with this strategy means staying in the design phase until they're resolved. The strategy should also take into consideration potential CSS browser compatibility issues. See "CSS and Browser Compatibility Problems" for my take on this subject.

Development Phase

I kicked off the development phase once I was happy with the design and implementation strategy. I set up a new theme folder and added a skeleton site.master file along with some empty CSS files.

I wanted the implementation of my design to adapt to changes in the browser window size. This means I couldn't just import a static image of my design into the web page and slot text into the various areas. I needed to slice up the static image of my design into a series of gradient strips that could be used with CSS styles to 'tile' back in the gradients. The gradient slice images (including the site header logo image) weighed in at a total size of only 9.4k, which is smaller than the heading banners on most sites.

I created an images folder in my theme folder for the gradient images. These images are thin repeatable sections of the my design background which are used to recreate the gradient fills in the different areas of my design.

The strategy I decided on involved recreating the design with markup and CSS as shown below.

The design is broken up into four distinct horizontal strips. Within each strip is a container div that holds a content area section and a side bar (or navigation bar) section. This approach allows me to apply CSS styles that recreate the gradients in each of the areas, thus providing the illusion of a translucent side bar. This approach also means that if the content area of an individual strip grows horizontally, so too does the corresponding side bar area.

Once the overall layout was in place, I added markup to the site.master file for the various controls of the side bar and the content area. The page you're looking at was the result of this effort.

As I progressed through each of the development steps, I tested the updated CSS with Firefox 2 and IE 7. Periodically, I did briefly test with IE 5, 5.5 and 6 just to make sure there were no major issues that would mean going back to the drawing board.

Testing Phase and Testing Environment

It is not possible to install multiple versions of IE on the same machine. At least not using the standard issue install files. Enter Multiple IE. While not perfect (the browsers will crash from time to time for no apparent reason), it enables you to set up a single VM with all versions of Internet Explorer, and whatever other browsers you want.

For testing my custom theme, I used a VM running Windows XP with Multiple IE installed in addition to Firefox 2, Opera, and a few others.

During this phase of the project, I made some small CSS refactorings to avoid CSS browser compatibility issues. One CSS modification involved setting the style of the body tag to the background color of the menu strip for IE 6. For some reason, the list items in the menu bar were not drawing with the appropriate background color. Instead of drawing with the background color of the containing div (which was apparently collapsing due to floating the contents of the div), it was falling right back to the body style background color. This modification resulted in the CSS working fine in all the browsers tested.

In addition to this I added a conditional comment to set the width of the site master page on IE 6, 5.5 and 5. I considered IE 4.0 and decided not to go there. I didn't use any CSS hacks.

There were no major issues during this phase. The only modifications made were purely to fix small CSS problems. This is down to both the approach used to get to this point, but also the fact that the design is quite simple. With a more complicated design, we could end up having to back-track to the development phase to fix problems.

Conclusion

Although the custom theme I've described above is quite simple, the process used to create it works quite well with more complicated designs. The key point to remember is not to over burden the design phase with implementation fears. The catch is that while doing this you must also try to produce a design that is not impractical. Finding the right balance between the two will help produce the most interesting designs that are reasonable to implement.

On the surface, developing with CSS is relatively easy. But then the reality of browser compatibility issues strikes and things become difficult for all the wrong reasons.

This forces the developer to choose one of four options.

1. Try to re-implement all or part of the CSS so that it avoids the compatibility problems.
2. Dump the entire feature that is causing the compatibility problems.
3. Use CSS hacks.
4. Use conditional comments.

People tend to get religious about the above options. Some only use CSS hacks, others only use simplified CSS that works everywhere. A lot of people loath conditional comments. Whatever your religion, there are some undeniable facts.

Riddling CSS files with CSS hacks is bad for two reasons.

1. It creates a minefield for future browser developers who have to ensure that new browsers don't break when they encounter the CSS hacks.
2. It makes the CSS files difficult to read and update.

Riddling markup files with conditional comments is bad because it also makes the code difficult to read and update. But it won't create a minefield for future browser developers.

With the above points in mind I tend to proceed as follows.

1. I try to avoid browser compatibility issues by refactoring the CSS to a point where it works everywhere.

I recently had to sort out a problem where an unordered list being used in a horizontal menu was causing placement problems on IE 5.5. The list item tags were being set to display as inline in the CSS style. By changing a single line of CSS (from display: inline; to float: left;) I managed to avoid the problem and the code worked in IE 5, up to 7, Firefox 2, Safari and so on.

2. If I can't avoid a browser compatibility issue, I use two conditional comment statements in the markup, and style overrides in the CSS.

When I was setting up the CSS for this blog, I was unhappy with how the page resized in IE 5, 5.5 and 6. By adding two conditional comments to the markup, I was able to provide any number of CSS style overrides to correct the problems. Specifically I added two conditional comments that wrapped the entire page markup as follows.

<body>    

    <!--[if lte IE 6]> <div class="ie6-below">  <![endif]-->

             <form id="Form1" runat="Server">

                     ...

              </form>

    <!--[if lte IE 6]> </div>  <![endif]-->

</body>

Then, I added style overrides in the CSS file where I wanted to correct problems. CSS specificity guarantees that my overrides will take priority over the original styles. For example, below are two styles, one that applies to IE versions 6 and below, and the original style to be used everywhere else.

.container

{

    min-width: 1016px;

    max-width: 1160px;

    margin-left: auto;

    margin-right: auto;

}

.ie6-below .container

{

    width: 1116;

}

Once the two conditional comments are added to the markup you can override as many styles as you like in your CSS files. These overrides are explicitly defined and don't make the CSS files hard to read.

3. As a last resort, I'll use a CSS hack.

I've seen all of the above problems before with Java ME while leading development at Upstart Games. Java ME is a small simple language that should run everywhere. It doesn't. Not even close.

We solved all of our Java ME porting problems (porting to 700 handsets on some projects) using a middleware solution based on conditional code. The first version of this got a little out of hand because we relied too heavily on conditional code and hacks. The second version was a huge improvement. Conditional code was kept to an absolute minimum. There were no hacks.