In the beginning, all we had were hacks.

To lay out web pages the way our clients wanted, with pull quotes, text wrapping, multi-colored table cells with space between the rows (but not the columns), then we had to hack, hack, and hack some more. Our hacks resulted in some impressively gargantuan code:enormous, indecipherable, triple-nested tables up and down the page, each with its own border, padding, spacing, and alignment settings, packed to the rafters with bloated font tags. But what could we do’

It wasn’t our fault we had to build these monstrosities; all we had to work with was HTML, a markup language created by a British software consultant in his spare time to enable scientists in Switzerland to share information about particle physics! I mean, come on! HTML was designed to display plain text in a hierarchical manner, period — no images, no three-column layouts, no multi-color fonts. It was never intended to create the magazine-like layouts we see on the web today.

But that’s what our clients paid us for, and so we hacked.

And as if that weren’t bad enough, the browsers we were developing for all rendered our code differently, leading to more hacks and more bloated pages as we strove for “cross-platform compatibility” (the day my producer learned that term was a dark day indeed).

Well, the kind souls at the World Wide Web Consortium have taken pity on you, poor Web developer, and in their infinite wisdom have formulated a solution that’s so beautiful in its simplicity, so beneficial for all parties involved (developer, client/boss, user), that you’ll break down and weep like Tammy Faye on a Sunday when you realize how much easier things are about to get for you.

The solution? So, so simple: web standards.

Contents Web Standards Review Ins and Outs of Hybrid Layouts XHTML Rules and Regulations Deconstructive Thinking Rebuilding Blocks

Web Standards Review

The smarty-pants crowd at the W3C realized that HTML wasn’t built to handle all the page-layout acrobatics Web developers were forcing it to perform, but they knew that we would continue using it unless they offered us a better solution. So they created a set of standards, which let us accomplish our goals in a much more efficient manner.

The standards you should follow for site design are as follows:use XHTML (the latest version of HTML that you’ve been working with all these years, but with a new twist) to organize your content on the page, and use CSS2 (a far more powerful and efficient presentation language than HTML) to format that content. These standards, along with ECMAScript (the W3C standard version of JavaScript) and the the W3C standard object model, form the triumvirate that is Web standards.

The beauty of Web standards is that they allow you to separate the structure of a page (“structure” here meaning the hierarchical structure of the content: <h1>, <h2>, <p>, <li>, etc.) from the presentation (the formatting of the text, the placement of items on the page, etc.). So instead of filling a table’s cells with
tags, spacer gifs,   characters, and font elements, just place your content on the page, surround each distinct section of content with its own unique id tag, and all the formatting info is pulled from your style sheet.

Of course, none of this would work if the browsers didn’t adhere to these standards as well. Thankfully, Microsoft, Netscape, Opera, et al. are beginning to see (to lesser and greater degrees) the value of a standardized language for the Web. Most modern browsers (Internet Explorer 8 beta, Netscape 7, Firefox 3, Safari) love standards, which means they each render your code in exactly the same manner … pretty much (hey, we’re still talking about the wild Web here).

What’s that, you ask’ Why should you care’ I assure you, the push for Web standards isn’t some crazy, pointless, “art for art’s sake” movement like recycling or organic foods. Oh no. There are real benefits to coding with standards, benefits to you, and to your client. Here are just a few:

Standards-Based Pages Are Tiny

Standards-based pages can be as much as 70 percent smaller than old-school pages (in terms of KB size). That means it takes you a fraction of the time to build each page (client loves you), your pages download lickety-split (client really loves you), and your client saves barrel-loads of real cash money in terms of bandwidth costs (client marries you, hires Liza Minnelli to sing at your wedding).

No More Multiple Versions of Anything

Because you’re sticking to standards, everything you build looks pretty much the same in every environment, thus eliminating the need to create special files for different environments. No more browser-specific style sheets, no more browser-detection scripts, no more designing one set of pages for the Web and one for cell phones and Palm Pilots. Of course, you don’t have to charge client any less, it just means you don’t have to do as much work.

More Cash Money For You

If they’re smart, all businesses will eventually move towards standardizing their sites to some extent, and they’re going to need someone who knows how to do it. That someone should be me. But if I’m busy, then that someone should be you. There’s going to be a lot of work in the standardization field over the next couple of years, and you want to be ready.

Faster sites. Simpler maintenance. Reduced bandwidth costs. Shortened development time. Everybody loves you. Got it’ Excellent!

Before we really get started, though, let’s first ponder the wisdom of “hybrid layouts.”

Ins and Outs of Hybrid Layouts

What we’re building over the following pages is known as a “hybrid layout,” meaning we’re still going to use tables to lay out our content, although to a much lesser extent than before (no more nesting).

Now there are some snooty, blue-blooded standards purists out there who will tell you that hybrid layouts aren’t entirely Web standards-compliant (true) because they still rely on tables for formatting rather than CSS2 positioning, so there’s no point to building them (false).

You have to learn to walk before you can run, and that’s where the hybrid layout comes in ‘ somewhere between full standards compliance and Paul Boutin’s down-and-dirty Web Standards for Hard Times.

A hybrid layout allows you to get comfortable implementing most aspects of Web standards (removing font tags, killing your nested tables) without having to dive right in to the more complicated subject of CSS positioning. It still delivers on many of the promises of a pure standards-based site (easier to build, easier to maintain, much faster download times), with the added advantage of displaying more or less correctly in older, noncompliant browsers.

Read’ OK. Let’s start with a quick XHTML rundown.

XHTML Rules and Regulations

I hate the word “rules.” It reminds me of my years in high school where, despite my immense unpopularity, I had a less than positive experience. So, instead of dwelling on the “Rules of XHTML”, let’s call the following list “Things You Have To Do Or Your Pages Will Look Like Modern Art.”

These new rules reflect the incorporation of XML into XHTML. If you’re not altogether familiar with either of these languages, here’s a quick overview:

XML (Extensible Markup Language) is sort of an uber-markup language, one that allows you to build all kinds of neat tools, including creating your own applications. Microsoft Word, Macromedia Dreamweaver, even the Mac OS X operating system rely heavily on XML to function. And the best part is, when you mark up your page using XML, you’re coding it to be compatible with any XML-based environment (databases, Palm Pilots, cell phones), which is one of the reasons they added XML to HTML to get XHTML.

XHTML (Extensible Hypertext Markup Language) is basically HTML re-written in XML. It looks and works just like HTML, but it’s more powerful because it plays well with the myriad of XML-based applications out there. It’s HTML, new and improved! HTML Plus! HTML Grande! OK, I’ll stop now.

XML is more consistent in its syntax than HTML, and therefore so is XHTML. But it means that when you write pages in XHTML, there are a few new rules you have to keep in mind:

Close Your Tags

Since XML requires you to close all your tags, XHTML does too. That means that a <p> tag must always be closed out by a </p> tag at the end of a paragraph, an <li> must end with </li>, etc. Get it?

Even your empty tags must be closed. That means tags like:

<img src="http://www.wired.com/images/archivebigbanana.jpg" alt="A Big Banana">

must now be written like:

<img src="http://www.wired.com/images/archivebigbanana.jpg" alt="A Big Banana" />

See that forward slash at the end? That’s me closing the image tag. Same for break tags ( <br> becomes <br />) and any other tags that require closure. (And don’t we all require closure?)

All Tags Must Be Lowercase

XHTML requires all its elements and attributes to be lowercase.

<TABLE CELLPADDING="6" CELLSPACING="14" BORDER="17">

now becomes:

<table cellpadding="6" cellspacing="14" border="17">

This rule doesn’t apply to attribute values, by the way. For example, you won’t have to lowercase the names of all your images.

Give Values to All Your Attributes

All of ‘em. Even the ones that don’t look like they should have ‘em. That means tags like:

<td nowrap>

must now read:

<td nowrap="nowrap">

It looks weird at first, but it’s actually easier on you because you won’t have to remember which attributes require values and which don’t. From now on, if it’s an attribute, it gets a value.

Quote All Your Attribute Values

If it’s a value (i.e., if there’s an equal sign in front of it), it gets a quote.

Use the Proper DOCTYPE/namespace Tag

Every time you create a new Web page, open it with the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">



<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">



<head>



<title>Your Title Here</title><br>



<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

Throw whatever else you want into the head of your document, just make sure you always have at least that much at the top of every page. (If you really want to learn the reason behind the new DOCTYPE, there’s plenty of information out there; it’s actually quite a fascinating…subject…zzzzz.)

Now, if you’re anything like me, you probably saw the word “rules” at the top of this page and skipped right down here to the bottom, which is fine. Just remember:Once you start coding in XHTML, if things don’t render properly, it’s probably because you didn’t apply all the rules listed here. Just pop back for a refresher and you’ll be fine.

Alrighty, campers, roll up your sleeves and let’s code!

Deconstructive Thinking

The best way to learn is by doing, so what I’m going to do here is walk you through the process of converting one of your old HTML pages (I’m sure you’ve got one lying around your hard drive someplace) to XHTML.

As a follow-along example, I’m going to convert a page from a site that my buddy Ben Allen and I developed for the Sears American Dream Campaign, a not-for-profit organization created by Sears to assist low income families in purchasing and maintaining their first homes (thanks you, Sears!).

Go ahead and open your page in your editor and save it as pagename_x.html. We’ll use this new page as our working page, and we’ll keep the old page as a reference for what the new page is supposed to look like when we’re done. Keep both pages open as you work.

Let’s begin by stripping the page of any HTML code that we’ve been using to modify the way the page looks. This includes:

• Any formatting attributes within the body tag:marginwidth, marginheight, link, etc.
• The table attributes cellpadding, cellspacing, border, and width.
• Attributes that you’d typically find within <tr> and <td> tags, such as valign, align, width, bgcolor, and background.
• All empty <p></p> tags, <br> tags, non-breaking space tags, and transparent GIFs that you’ve been using to create space within your document.
• All font tags and the attributes/values they contain.

Don’t be timid; I want you to wield that Delete key like a sledgehammer! And remember, we’ve got our original page saved in case we screw something up, so don’t hold back.

Once you’ve finished, step back and have a look at what’s left. Now switch back to the code in the original document. ugh! Ach! All those font attributes, spacer pixels, and <br> tags! My eyes! My EYES!

Let’s switch back to our working document. This is how all the code you write should look from now on. See how cute and tiny it is’ Think how fast it’ll load! Look how easy it is to find and maintain the content within the code! And imagine if you had built it this way in the first place. Why, you could have done it in half the time!

Go ahead and preview the new page in your browser. What you should see is a page that looks very similar to Web pages back in 1996:a page with no formatting, just text and graphics. Here’s what mine looks like, sans HTML formatting:

Standards-friendly code, 1996 look (here, take a closer look).

Now it’s time to format the page the way God (or at least the W3C) intended. Let’s dive in, shall we’

Rebuilding Blocks

(Note:I’m assuming here that you know how to create a style sheet and link to it from your pagename_x.html page. If you don’t, you can read all about it right in Mulder’s Stylesheets Tutorial.)

The first thing we’re going to do is quickly replace all the formatting information that we removed from the <body> and <table> tags earlier on. Super easy:

 body, table, tr, td {

 margin:0;

 padding:0;

 background:#ffffff;

 font:12px / 1.5 Arial, Helvetica, sans-serif;

 color:#19306A;

 }

 

There, with that one style definition we just replaced hundreds of <font> tags and saved Sears thousands of dollars in bandwidth costs over the coming months. Hey, I should’ve asked for more money.

The next step in the rebuilding process is to go through the remaining code and divide the page into sections, depending on how each section is to be styled. I emphasize the word “divide” because the W3C provides us with a formal way to do this with the <div> tag. (<div>’ Divide’ Get it’) We’re going to give each unique section its own <div> tag so we can format those sections using CSS. Make sense’

There are six pretty obvious divisions on my test page:the top row of navigational icons, the secondary row of navigational elements, the column of photos down the left hand side, the column containing the copy (including the pink-ish header), the bottom row of navigational elements, and the paragraph of copyright information at the bottom of the page. We’re going to start at the top and work our my way down.

The top navigation row: Since this is just bunch of images that sit flush up against each other, we’re going to take them out of their table altogether and surround them with the <div id=”topNav”></div>. The formatting for topNav looks like this:

#topNav {

width:750px;

margin:0;

padding:0;

}

We don’t really need a div tag for the top nav since there’s no formatting going on, but we’ll give it one in case the client decides later that she wants more of a margin between the navigation icons and the edge of the page. That’s one of the beautiful things of using CSS for presentation:You make changes to the style sheet and they’re immediately reflected on every page of the site.

The secondary navigation row:This set of navigation elements is also just a group of images bunched together. They don’t need a table either, so we’re going to kill theirs as well (Die, table, die!) and surround them with <div id=”subNav”></div>. The purpose of their div tag is to position this set of images 10 pixels from the topNav div above them, and 199 pixels from the left hand side of the page. Piece of cake:

#SubNav {

margin:0px;

padding:10px 0px 0px 199px;

}

See how much easier it is to use padding (which in CSS2 I can control on all four sides of an element independently) rather than all those jive-ass single-pixel GIFs and table cells we used to use before’ Why would you ever want to go back’

The photo column: The photo column is actually the trickiest part of this page. We want each photo to be centered within the column, but sadly there currently isn’t any way to center images within a column using CSS2. You might be tempted to put align=”center” in the photo columns <td> tag, but then you’d have to put it on every page on the site, and we’re not down with that kind of clutter anymore.

Luckily, there’s a hack that lets you accomplish centering. (Yes we’re still hacking ‘ but it just wouldn’t feel like Web development if there wasn’t at least one workaround, right’) You can find it at A List Apart, or you can steal it from me:

#photos {

width:300px;

margin:0px auto;

text-align:left;

text-align:center;

}

The copy column: There are a couple of things going on here. First, we need to restore the formatting to the header:

h1 {

font:bold 35px/1 Tahoma, Arial,  sans-serif;

color:#E31E46;

}

Next, we need to format the copy. We’ve already declared the font face, size, etc. in the body id, so all that’s left is to add the indentation that my paragraphs require. I’m going to save myself some time and use the

tag as my class. That way, everytime I enclose copy in a <p> tag, the copy will get a left margin of 25 pixels automatically. Here’s what the style looks like:

 p { margin:0 0 15px 25px;}

The bottom navigation row: All I need here is a little space between the copy above and the images, plus I need it to align with the left side of the text, which we pushed over 25 pixels from the right.

#bottomNav {

margin:40px 0 0 25px;<br>

}

The footer: This is another easy one. I want the font color, size, etc, to match up with what’s on the old page, plus I want 15 pixels of space between the bottom nav and the footer, and another 15 pixels between the footer and the left hand border of the page.

#footer {

position:relative;

width:650px;

font:10px Arial, Verdana, sans-serif;

color:#666666;

padding:25px 30px 20px 15px;

}

And that’s it! To summerize the conversion process, we Strip the page of all outdated HTML formatting, we Divide the freshly stripped page into various sections depending on what formatting they’ll require, and we Format our new divisions using CSS2. If it sounds easy, that’s because it is!

Ahh. No spacer pixels. No column spans. No nested tables. Our pages are two-thirds the size and they take half the time to build. And if your client wants a little more space between the left hand margin and the footer across the 87 pages you’ve just built. Feel free to charge for three hours of work, but it’ll really only take five minutes to change that space on every page of the site.

What’s that you smell, Pure genius?