You CAN Use CSS Today!!!
Web Review
August 1999
As most of you are no doubt aware-- either from reading my Sense of Style articles, or perusing the Master Compatibility Chart, or simply from trying to use CSS is your own page designs-- there are a whole lot of bugs, inconsistencies, and downright weirdnesses 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 which doesn't often involve client other than myself and my department.
Most of you are quite the opposite, and probably don't have the time (or energy) to spend in figuring out what's safe to use, and what isn't. It was for this reason that we created the CSS Compatibility Chart in the first place. However, Chart or no, it is possible for designer to use CSS right now-- today-- in such a way as to save time, energy, and maybe even money. After all, the time you spend on page design is worth a lot.
This article will show you how you can employ CSS to make you job easier, simply by choosing the right approach and the right authoring environment.
Protoyping Made Easy
First, you need to understand HTML inside and out, to the point that you're more comfortable writing the code yourself, rather than relying on a page layout tool to do the work for you. 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 out your design, you'll need to get in there and write the code yourself.
Why? Because you need to be able to attach classes 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. It's a fairly typical design, but that's okay.
Page Title Here | |
sidebar links here |
main content here |
What's need, 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>
This is simple enough for the moment, and yet it can already demonstrate the point. With this simple layout, we can assign styles involving color, and see how the combinations work. Here are two examples, with styles:
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;}
|
The advantage here is that with only minimal editing of a file, the appearance of the document can be changed radically. This is especially useful when you're trying to find a good set of colors which work together, and in meetings, it 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 extra meetings required.
One Browser = Faster Development
The important thing here is to stick to one browser while designing. No, wait! This isn't a call to ignore browser inconsistencies, nor to slap "This page best viewed with..." buttons on all your pages. Far from it! While you're in the design phase, though, you're better off not worrying about the bugs in 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.
The first thing you probably want to do is pick a browser which 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 yet an actual browser, and it isn't even a 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 layout of the page, or its styles, reload the page in your design browser of choice. Keep it up until you've arrived at a final design.
During this phase, it's better to leave out graphics as much as possible. Sure, your page might look a little better with a dropshadow along the sidebar, but you can keep it in mind as you work. If you go to the effort of creating that dropshadow, and then change your design so much that the shadow becomes unnecessary, you've wasted time. Similarly, making up graphics for your sidebar links is wasted effort 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.
Note: it can be to your advantage to have a "toolbox" of graphics at your disposal. This would ideally contain a number of background graphics in various colors, as well as dropshadow graphics which you can apply to an element using stylesheets. For example, you could add a dropshadow to your sidebar like this:
TD.sidebar {background: silver url(dropright.gif) top right repeat-y;}
If you already have that dropshadow 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 settled on a set of styles. You have the page looking pretty close to what you want the final version to be, and you're ready to create the various graphic adornments necessary to finish it off.
Hold it! First, we have to do the tough stuff. We have to make the page display as consistent as possible in as many browsers as possible. This is when you take your design and load it up in Navigator 4.6, and on browsers on other platforms (like Navigator for UNIX), and 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 instead, each situation is a new point of learning. In the process of "debugging" a sophisticated page design, you will learn more about cross-browser design, and CSS support and behaviors, than any ten articles could teach you. 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 table to lay out your page anyway. By protoyping 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 your debugging, you'll have a page that looks its best in as many browsers as possible. At this point, it only remains to add whatever extra decorations you need to make the design look polished, and 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; it will keep 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 like, "O Great Deity of the World Wide Web."