It’s Pink, Makes People Sneeze, and Reminds Me of Design

Jeremy Hilts, Web Developer

The recent Cherry Blossom Festival here in D.C. really got me thinking about aspects of good design. A couple of weekends ago, I dug out my trusty Canon SLR and went to town. Granted, the only thing that ever comes of my photography is some new wallpaper for my work computer; but the experience is always half the fun.

As far as design relates to my particular trade, there are usually two schools of thought that go into it: the front-end design and the back-end design. Either of these two things can make for a really good site, or a maintenance disaster. Among Q’s developers, there’s a lot of talk about a term that I’d never heard before I worked here: “technical debt.” The idea is, simply, that if it was a nightmare to make, it’ll probably be a nightmare to maintain.

There are a handful of XHTML/CSS “gurus” around the office, and technical debt often falls in as a topic for discussion – things like proper use of HTML tags, IDs vs. class names, and browser-specific selectors. I find that browser compatibility becomes less of an issue the better formed your XHTML markup and CSS is; however, certain browsers will always be a nightmare (*cough*IE6*cough*).

Allow me to elaborate a bit on that point. You have three areas relating to web design: the back-end, the XHTML (middle-end? front-end part one?) and the CSS (front-end part deux?). The back-end deals with business logic (you submitted a form, what does it do?), the XHTML deals with the content and basic backbone (what you should be seeing), and the CSS deals with the overall look and feel of the site (the pretty). In an ideal situation, three separate people will be working on these different aspects, decoupling them enough to make them easily maintainable. In a real-world situation, XHTML and CSS are typically wrapped into a single person. I often do all three.

Writing sane CSS is a topic for another day; there are a million books about it, so I would be doing a great disservice by paraphrasing. XHTML, on the other hand, is quite a simple animal. Actually, it’s so simple that most people take it for granted. It’s flexible enough that (nearly) any tag can represent or replace (nearly) every tag. It’s this flexibility that makes writing or maintaining XHTML like a pleasure cruise down the River Styx. Since any tag can represent pretty much anything, it’s quite possible to make an entire website out of DIVs (or P’s, or SPANs, or even HRs) and class names. As a matter of fact, I’ve seen a number of them.

Example (of what not to do):

<div class="body">
<div class="header">Hi, I'm the page header</div>
<div class="subheader">This is what my page is about</div>
<div class="content">Welcome to my website, I would like to bring your attention
to the growing owl population</div>
</div>


Example (of well-formed goodness):

<div class="body">
<h1>Hi, I'm the page header</h1>
<h2>This is what my page is about</h2>
<p>Welcome to my website, I would like to bring your attention
to the growing owl population</p>
</div>


Making an attempt at using the proper tags for a given context will make things more clear to anyone who has to take over afterward, make you look good, and will avoid the impending laughter from view/source geeks (guilty). It also allows the CSS coder to write single sets of styles that cascade seamlessly throughout a website giving a consistent look and feel. But mostly, it keeps you from getting laughed at. Also, inline styles are bad.

In our next episode, I’ll try to elaborate on the IDs vs. class name debacle. Tanoshimi ni, ne? (look forward to it!)

Share and Enjoy

•