argument

Article by David Shea of www.mezzoblue.com. A must-read!!

PERMALINK: www.mezzoblue.com/archives/2004/04/30/a_roadmap_to/

04/30/04

A Roadmap to Standards

This afternoon I was asked by a friend what I would recommend to an old designer who wants to learn more about web standards, CSS, XML, and XHTML.

This is a perfect example of when an email response is better posted here for a wider audience (and Google). So here's my answer: this is a comprehensive, informal, and somewhat long-winded roadmap for anyone who has heard about web standards, thinks they might want web standards, but doesn't know where to start.

Stop! Before you do anything, the most important thing you can do for your learning process is accept that a) it's going to take time, and b) you will be frustrated along the way.

But you're not alone. Plenty of us who have taken the plunge into standards went through the same, and there is a growing body of work devoted to helping make your life easier. The old-timers had to figure out the hard way all the tricks and techniques we now take for granted; lucky folks who came in later (myself included) can benefit from their sweat and tears.

In the end, when your skill using standard-based design eclipses your skill using old-school table-based methods, you'll look back and marvel at how much more sense it makes to layout a page with CSS. Oh sure, the actual methods used might not make much sense (considering there are better options in the CSS2 spec than what we currently use) but we have a major browser manufacturer to blame for their lack of support.

Uh, I seem to have wandered. Sorry, that's another thing you'll have to get used to: unbridled hostility against Internet Explorer. It'll take some experience to understand why, but you'll know exactly what we mean in short order.

So. On to the practical information you can start using immediately. First, run and buy Designing With Web Standards. Don't even think about it, just do it. Got it? Good, now don't let it collect dust ' read it. Everything I'm about to cover is detailed in DWWS. It's equal parts manifesto (WHY would you want to do this?) and tutorial (HOW do you do this?). You need it.

Now. The first thing to do is get into an XHTML mindset. Whether you choose HTML 4.01 or XHTML 1.0 Strict (there are reasons to go with either; ignore them for now, and then ignore them even more, until you're ready for some mind-numbing drudgery), it all begins with a DOCTYPE. Telling a browser which language your document is marked up with isn't only a good idea, it prevents unwanted rendering glitches that will otherwise drive you crazy. Think of it like this: if I want to fly to Chicago, I have to tell my travel agent of choice where I want to go. Sure, it might be fun to take my chances and see where I end up, but it's not exactly practical. Setting a DOCTYPE ensures I get to my destination of choice without unintended side-trips to Vienna.

Next goal: well-formed markup. This is pretty easy to grasp, actually. Always quote your attributes (ie. , and <input type="text" />). Don't improperly nest tags; close them in the order you opened them. And if you open a tag, close it again; every tag, or element, requires an opening and a closing correspondent.

A quick diversion here: somewhere along the way, tags became 'elements'. Same syntax, different theory. Call them what you will, the proper label is now element; maybe it always has been. I don't know. No one ever explained this to me.

So anyway, each element needs to be closed properly.

 

Now there's one more little confusing thing about XHTML attributes: they always need to have a value, even when that value doesn't make sense. Example: <input type="radio" checked="checked" />. You can get away with just checked in HTML 4.01, but XHTML needs the redundancy.

Finally, XHTML requires all your code to be in lowercase. HTML doesn't differentiate, but XHTML uses XML syntax, which is case-sensitive. And the case ends up being lower.

That's it for markup! You're done! Take a breather, grab a cerveza, and chill out for the afternoon. Because that's only step number one.

Now that we've got you writing proper HTML/XHTML, try running it through the W3's validator. If you've crossed your i's and dotted your t's (or in this case, quoted your attributes and nested your elements) you'll achieve a nice yellow-on-blue success message. Learn to love this colour/text combination, it can be your best friend.

Why is validating important, or even relevant? Because poorly-written markup is completely unpredictable; you end up relying on a browser's error-handling, and even though most browsers are very good about this, it's a bad practice to rely on it. Hey, it's what got us into the non-standard, proprietary browser wars in the first place. (Microsoft was able to compete with Netscape in the Netscape-dominated world of 1995 because IE was built to handle errors exactly the same as Netscape.)

The single point is, validating helps you spot errors in your code, which in turn ensures more consistent rendering of your page. The very first technique I try when debugging problematic layouts is validating my code. You should too.

Yeah, okay, it's tough when you first validate your first site and get back a list of 78 arcane errors. Unfortunately, though the validator helps, it's not perfect. It's run by volunteers who are doing their best, but sometimes the error messages are as helpful as Vogon poetry. The good news is that problems cascade, and if you can find one missing

tag, for example, a lot of the time you bump that number down to 24 errors without doing anything else. The short of it: it looks bad, but it's often not.

 

Now that you're validating, you're following the letter of the law. But as with many real-world laws, at this point you're adhering to only the rigid guidelines of the rules and missing the bigger picture about why those guidelines are there in the first place.

The next step is to take this well-formed markup structure you've built for your document, strip out the presentational attributes that have been deprecated in some of the more recent DOCTYPES, and move the presentation into a completely separate file. This is the infamous separation of structure and presentation, and this is where CSS comes into the picture.

It's like this: your text is content. Content is nice, but without any hints about the content's structure (which includes things like spaces and headers and lists) you end up with a jumbled mess of text. Completely unusable. Structure is an extra layer which breaks down that messy text into logical groupings and organizes them in a way that conveys extra information about individual elements in that document. How that information looks may be implied by the structure (for example, you'll most often find that a primary page heading will be larger than the body text) but it doesn't dictate it any further.

That's where presentation comes in. Presentation is the formatting cue that tells the primary page header to be red, italicized, and 150% of the body copy's size. Presentation is an extra layer of information on top of a document's structure, that builds up the (non-visual) structure into something far more appealing to the eye. CSS is the presentational layer, and it can take a very simpy marked up document, and turn it into something amazing ' view the css Zen Garden for a live demonstration of this in action.

So what's the best way to start separating your presentation out of your structure? Consider any HTML element or attribute that offers a visual cue to be an offending piece of legacy code. It's time to start killing those bgcolors and

tags. Here's a pop quiz:

 

1. <code><center><h1><font face="Verdana">This is my first web site.</font></h1></center></code>
2. <code><table border="0" cellpadding="0" cellspacing="0"></code>
3. <code><body bgcolor="#ffffff" topmargin="0" leftmargin="0" marginwidth="0" marginheight="0"></code>
4. <code><td bgcolor="#ffffff" valign="top" align="center"><p>They're coming to take me away...</p></td></code>

Got your answers ready? Great, compare to the list below. These are proper structural elements without a trace of structural formatting:

1. <code><h1>This is my first web site.</h1></code>
2. <code><table></code>
3. <code><body></code>
4. <code><td><p>They're coming to take me away...</p></td></code>

That's it? That's it.

and elements, but it's hard to say without surrounding context. Tables aren't deprecated; they can still be quite useful. But they should be used properly ' to contain data that's structurally tabular. So we've stripped the formatting from our page. Hooray. What now? Those are some ugly elements, all Times-New-Romaned and linear. Where's the interest? Where's the compelling visuals we were promised? Head back to the Zen Garden example. See the lovely designs? See how different they are? The key here is that underneath each is the same XHTML, just as bland as your currently-unformatted document. No really, it is. Having a bland and ugly base is a good thing, in fact. What you may have noticed is that this unformatted HTML looks an awful lot like the web of 1994 (if you were around back then). In fact, with a few notable exceptions, that's what it is. This stuff is as old as the web itself. 's have been around since the days of Mosaic. Which, as you may have guessed by now, will still handle a properly-structured page with surprising fidelity. Try saying that about a late-90's table-fest. The benefits don't end there of course. Accessibility to those with special needs is almost free, search engine optimization is built-in, bandwidth costs go way down (along with development times), and on and on and on. Jeffrey Veen wrote up the Business Value of Web Standards late last year, and Roger Johansson expanded on the benefits and techniques of standards-based design with his recent Developing With Web Standards. CSS is well-supported across all the major browsers today, and there are countless resources for learning the syntax, the basics of CSS layout, and the advanced theory behind high-impact CSS-based design. I'll point you to a few of the better ones: WestCiv offers an ongoing, free CSS course that will help you get started and bring you up to speed in a hurry. Andrew Fernandez has indexed a huge listing of CSS resources that should help you no matter where your skill level is. Eric Meyer has written a bunch of books that you should have on your desk, including the project-based Eric Meyer on CSS and its follow-up More Eric Meyer on CSS (no, really, that's what it's called). His O'Reilly-published reference CSS: The Definitive Guide is in its second edition, and should be on your desk.