You Can Use CSS Today

As most of you are no doubt aware—either from reading my Sense of Style articles, perusing the Master Compatibility Chart, or simply from trying to use CSS in your own page designs—there are a whole lot of bugs, inconsistencies, and downright weirdness in CSS support. I prefer to think of these as interesting challenges. But I'm lucky: I have a job which isn't incredibly deadline-driven, and that doesn't usually involve clients other than myself and my department.

Most of you have a much different situation, and you probably don't have the time (or energy) to spend figuring out what's safe to use, and what isn't. That's why we created the CSS Compatibility Chart in the first place. However, chart or not, it's possible for a designer to use CSS right now, today. And believe it or not, CSS can save you time, energy, and maybe even money. I'll show you how you can employ CSS to make your job easier simply by choosing the right approach and the right authoring environment.

The key to prototyping

First, you need to understand HTML to the point where you're comfortable writing code yourself, rather than relying on a page layout tool. Sure, you can start by sketching out a page's appearance on paper, or using something like Freehand or Photoshop, but when it comes time to test your design, you'll need to get in there and write the code yourself.

Why? Because classes need to be attached in all the right places. Our example will be a page which has a title across the top, a sidebar for links, and a list of products.

What's needed, in order to make things work, is a class for each cell in the table, like so:

<TABLE cellspacing="0" border="1" cellpadding="3">
<TR>
<TD colspan="2" class="pgtitle">Page Title Here</TD>
</TR>
<TR>
<TD class="sidebar">sidebar<BR>links<BR>here</TD>
<TD class="main">main content here</TD>
</TR>
</TABLE>

Even though this sample is simple, it demonstrates the point. Now we can assign styles involving color, and see how the combinations work.

TD.pgtitle
  {background: white; color: maroon;}
TD.sidebar
  {background: white; color: red;}
TD.main
  {background: gray; color: yellow;}

TD.pgtitle
  {background: #555555; color: white;}
TD.sidebar
  {background: #333333; color: silver;}
TD.main
  {background: silver; color: black;}

With only minimal editing of a file, the appearance of the document can be changed radically. This is especially useful when you're searching for colors that work well together. In meetings, this can be a life-saver. How many times have you heard, "Can we see that in a different shade of blue?" If you're using styles as described, you can show the changes right then, right there—no more meetings required.

Design to one browser

Remember to stick with one browser while designing. This isn't a call to ignore browser inconsistencies, nor to slap "This page best viewed with ..." buttons into your design. Far from it! While you're in the design phase, though, you're better off not worrying about the bugs from one browser or another. Until you've picked your final design, why go to the effort of making the pages cross-browser friendly? That part can wait.

You do, however, want to pick a browser that is pretty good at CSS. That would leave out any version of Navigator before version 5, which (as of this writing) isn't yet available. Internet Explorer 4.x and 5.x are good choices, and if you're a Windows user, so is Opera 3.6 or later. If you're feeling brave, you can use the preview builds of Mozilla from M8 and later—but since Mozilla isn't an actual browser as of right now, (it isn't even in beta yet) this path should be taken with caution.

At any rate, once you've picked the browser you prefer for the design phase, start writing HTML and CSS. As you change the page layout and styles, reload the page in the "design" browser. Keep at it until you've arrived at a final design.

During this phase, it's better to keep graphics to a minimum. Sure, your page might look a little better with a drop shadow along the sidebar, but you can keep it in mind as you work. If you go to the effort of creating that drop shadow, and then change your design so much that the shadow becomes unnecessary, you've wasted time. Similarly, creating graphics links for your sidebar should also be avoided while you're still experimenting with the look. If you suddenly change from red text to orange text, it's much better to be able to change actual text than to have to edit graphic files.

It's helpful to have a toolbox of graphics at your disposal. This would ideally contain several background graphics in various colors, as well as drop shadow graphics which you can apply to an element using style sheets. For example, you could add a drop shadow to your sidebar like this:

TD.sidebar {background: silver url(dropright.gif) top right repeat-y;}

If you already have that drop shadow graphic available, it's easy to try it out to see how it works. The key here is to avoid generating project-specific graphics before you're done with your page design.

Done? Now for the hard part

So you've finally decided on a set of styles. You have the page looking pretty close to your vision of the final version, and you're ready to create the various graphic adornments necessary to finish it.

Hold it! First, we have to do the tough stuff. We have to make the page display as consistently as possible in as many browsers as we can. This is when you take your design and load it up in Navigator 4.6, on browsers from other platforms (like Navigator for UNIX), in IE3, and Lynx.

For each browser you use to look at your page, you have to ask a series of questions: How does it look? What's causing any problems? How can you fix them?

There aren't any universal answers for these questions, but each situation is a new point of learning. In the process of "debugging" a sophisticated page design, you'll learn more about cross-browser design and CSS support and behaviors, than from any ten articles you might read on the subject. The CSS Compatibility Chart can help a lot during this process, but eventually you'll become experienced enough to only need it on occasion.

The irony here is that, in all probability, you're going to end up replacing a lot of your styles with table-based markup. This is, of course, exactly what CSS was designed to make unnecessary, but let's be honest: You're going to use tables to lay out your page anyway. By prototyping the page in CSS, you'll have a good idea of how the page needs to be "table-ized" once it's time to do so.

And, of course, when you're finally done with debugging, you'll have a page that looks its best in as many browsers as possible. At this point, you can finally add those extra decorations you want to make the design look polished. Now you're ready for your next challenge.

Go forth, young grasshopper

The method described here is, frankly, how I learned nearly everything I know about page design and CSS. The Test Suite helped, sure, but there's nothing like your own real world examples to teach you how CSS really works, both in theory and in practice. I've put together more than one project in this manner, and in comparing these designs with earlier efforts, I can readily see how much better the later designs were, not to mention how much more quickly I arrived at them.

In short, I can't recommend this approach enough. It will save you all kinds of time in the design process, and let you try out different page designs with ease. This approach will also get you in the habit of creating structured documents, and it will sharpen your design skills to the point that you'll be able to envision the kinds of styles you need to achieve a given design just by thinking about it. At this point, don't be surprised if your friends and co-workers begin addressing you using titles such as, "O Great Deity of the World Wide Web."

Previously in Sense of Style

Using Style Sheets To Control Fonts
CSS: If Not Now, When?
Making Styles and Tables Play Nice