OK, so you think you understand the four principles from last time. How do you build with them?

First, Catch Your Rabbit

The old saw applies to far more than cooking. Your website is meant to contain content. Yes, that seems obvious, but if it’s so obvious why do so many start designing before there is content?

Design From The Content Out

Even if you’re designing a template through which content retrieved from a database will be poured, you still need to start with the content. Collect representative samples of every kind of content that will be poured into this template, and start using (X)HTML to mark it up. Andy Clarke, whose book Transcending CSS should be required reading for every web designer, calls this process “Content-out design.”

It should be common sense. You can’t expect to build a solid structure on a weak foundation. And the document markup is the foundation to which your design will later be applied. So make it a solid foundation by using good semantic markup.

Web Design Is Like An Ogre

It has many layers.

Processes for producing these layers go by many names, just two of the most famous being “Graceful Degradation” and “Progressive Enhancement.” It’s not my purpose here to take sides; the process I’m writing about should be able to be used with all of them. If you want detailed information about them, look elsewhere.

The basic premises of both are to create layers of capability in the design, the least capable browsers seeing the lowest levels, and advanced levels being offered to more capable browsers.

So, keeping this in mind, you either start with highest level of browser and work down (graceful degradation) or with the lowest level of browser and work up (progressive enhancement). At this point we’re only worried about specific browser capabilities, not user capabilities or media capabilities.

The last two principles from part 1 will govern what you do during this layering process. Remember as you build up/down the layers, the goal is to present a pleasant user experience at each level (Principle 3—”Unity is not unison,” it’s OK to show different browsers slightly different views) and nobody gets screwed (Principle 4—”Above all, do no harm”). OK?

Semantically Classy

Around this point someone always demands a ruling on what class names should be. Sorry, I decline to play that game. I’ve written before that I’m not creating a checklist for you to follow; I expect you to do some thinking for yourself and to make choices using “your experience, as guided by intelligence.” I’ll happily tell you what I practice, but you can feel free to ignore my opinion and follow your own guru. The Reactive Layout process will cope, no matter which naming convention you choose to follow.

The two extreme views in this are “class name imgleft is perfect” and “class name imgleft is evil.” Supporters say it’s good because reading the class name tells you what’s happening here, without making you dig through a possibly complex CSS file to find out. This makes it easier to remember and use the class, especially for a client that may be handling the update of old and creation of new content. Detractors say it’s evil, because the CSS could have changed between now and the time the class was named, so you don’t in fact know what’s happening, and could easily get confused. If you follow this edict, then you provide your client with good documentation of what classes to use and what each of them mean, stylistically.

The conditions under which I’m most against presentation cues in class/id names is when we’re talking about the content stored in the database. The reason is that if I change that in future redesigns, I’ll have to walk the entire database looking for class names to change. But even then, I don’t exclude them completely. I just document the ones that are there, so when redesign time comes I’ll know what they do, and I’ll carry their definition forward into the new design, creating new class names rather than reusing them if I want different styles applied.

When it comes to the template, I’m less rigid. In many ways, the template itself is presentation, don’t let the fact it’s in an html file fool you. But if I write presentation info in a template class/id, I discipline myself to edit the template file(s) when the presentation cues no longer apply.

Now that you’ve got a semantically correct markup file and a properly layered design, you’re done, Right? Wrong. Now you have to teach your design to adapt to circumstances beyond your control. And that’s coming up next time.