By now we all know the benefits of “web standards” - creating sites where content and presentation are separated by use of semantic XHTML and CSS. Early adopters of web standards have long extolled the many payoffs, which include:

But how realistic is this last point, really? Table-based layouts might be a nightmare of nested cells and font-tags, but CSS-based sites can be outlandishly overwhelming with their many, many nested divs and spans, their plethora of IDs and classes, and their multiple style sheets with their many hacks. Sites that I myself built just a year or two ago would be impossible to completely redesign without starting from scratch. So although it’s nice to think that all web-standards-based sites are Zen Garden like, the truth is that many, many of them are just as difficult as their table-based counterparts to redesign.

What Can Be Done?

So, what can we as developers do to make the hype real? Part of it comes naturally - as we develop our skills as CSS mavens we logically begin to create more organized, simplified, and versatile style sheets, we move away from creating unnecessary classes and IDs and begin to make better use of the cascade, and our XHTML becomes more simplified and more semantically structured.

But I think we can take it a step further. I suggest that we begin to code our XHTML first, independent of what we plan for the layout to be. Let’s code our XHTML as if we plan to have 10 different designers apply their own unique layouts to it. If we can do it that way, then we will be able to execute minor or even major design overhauls without touching a single page in the site. And what’s more, any other developer will be able to do the same. That would be a true realization of the hype.

Seeing the Light

I first began to see the possibilities of coding this way when I was charged with implementing the realign of Energy Muse, a site I had coded a year before. Energy Muse had redone their logo, and therefore wanted a site-wide facelift that would reflect their altered branding. This was the first time that I had been involved in the realign of one of my own sites since I had begun to master CSS. I was amazed to discover how easy it was - to my surprise and delight I found that I did not have to touch the html even a little bit! Uploading a few new images and an updated CSS sheet was all that was required to transform this:

Into this:

And then (in a later realign) into this:

Now, while this was exciting, it’s not quite as impressive as it could be, because the basic structural layout of the site was unchanged. It really was just a facelift, as opposed to an extreme makeover. But it was enough to inspire me to really try to do it right next time.

Recently I coded the Deluxe Digital Media website with the idea in mind that we would eventually have multiple layouts to choose from - our own mini Zen Garden. This was, I believe, the first time I’ve really done it right in terms of my markup. And it was this experience that was the impetus for this article.

So What Does Doing It Right Mean?

Besides trying to clear your mind of your intended layout, there are a few other things to keep in mind when writing the XHTML first.

Semantic Markup

Obviously, the most important thing to start with is making your markup semantic. Semantic markup is simply the use of the proper tags for content elements – heading tags for headings, paragraph tags for paragraphs, list item tags for list items, etc. In addition to the basics, you might be wise to also use tags like <blockquote> and <cite>, in addition to <abbr>, <em> and the like. For a more in-depth look at semantic markup, including some tags you may have forgotten about, see Blue Anvil’s Guide to Semantic Markup.

Flexible ID and Class Names

In an effort to keep everything about our markup layout-independent, try to give IDs and classes names that relate to their structure, rather then their appearance. So, instead of id=”left_column” try id=”main_content”, instead of class=”small” try class=”copyright”, etc.

Enough Hooks

As CSS mavens, there’s one thing we know we need to have in our markup, and that is enough “hooks” to attach our CSS to. Traditionally, we put these hooks in as we need them. In our new improved way of doing things we will have to put them in wherever we might need them.

For example, in the Deluxe Digital Media site we use live text for our navigation - no images, and nothing fancy. But instead of this:

<ul>
  <li><a href="/index.htm">Home</a></li>
  <li><a href="/services/">Services</a></li>
  <li><a href="/clients/ ">Our Clients</a></li>
  <li><a href="/about/">About Us</a></li>
  <li><a href="/contact/">Contact Us</a></li>
</ul> 

I wrote it like this:

<div id="main_nav">
  <ul>
    <li><a href="/index.htm"  id="mnav_home"><span>Home</span></a></li>
    <li><a href="/services/"  id="mnav_services"><span>Services</span></a></li>
    <li><a href="/clients/"  id="mnav_clients"><span>Our Clients</span></a></li>
    <li><a href="/about/"  id="mnav_about"><span>About Us</span></a></li>
    <li><a href="/ontact/"  id="mnav_contact"><span>Contact Us</span></a></li>
  </ul>
</div><!-- end main_nav --> 

Now, I have the hooks I might need to do something more complicated with the navigation in the future. The surrounding div gives me an additional element to style and attach margin, padding, borders, or background images to. The spans surrounding the text will allow me to hide that text in the future if I wanted. The unique IDs for each link will allow me to assign different background images to those links. Together, the spans and IDs allow me to use image replacement techniques for my navigation elements. The possibilities become endless.

Additionally, I would be inclined to add a couple extra divs at the top and bottom of the body of the document to ensure maximum agility. Something like this:

<div id=”top”><span></span></div><!-- end top -->
-- CONTENT --
<div id=”bottom”><span></span></div><!-- end bottom -->  

Actual Content Behind Flash or Descriptive Images

You might notice that the Deluxe Digital Media site uses some Flash animation on the front page. This animation, similar to a large descriptive image, contains important information. This is information that cannot be read by screen readers, nor accessed by handheld devices, nor indexed by search engines. For these reasons, I have made this information readily available in semantic markup. The markup is hidden. But, since I have wrapped my Flash movie in a div with an ID of Flash, I could in the future decide to unhide the markup and hide the Flash instead. Now, in a case where there is only one instance of Flash on the home page it might make more sense to just go in and remove it - but if you had Flash on multiple pages and perhaps wanted to serve up a Flash-alternative site (or simply a printer-friendly site) with the switch of a style sheet then this method would really come in handy.

Wait a Minute: Is all this Semantic?

Now I know that one of our favorite pastimes as standards advocates is arguing over extraneous markup and glorifying the leanest, meanest code possible, however it seems to me that sometimes we can take this too far and actually do ourselves a disservice. Yes, it’s true that the markup I am advocating includes some additional divs and spans and such. But I ask you to consider what makes more sense - creating the cleanest, leanest, meanest markup possible that we can revel in and pat ourselves on the back for, but which some poor developer in the future will have to completely redo in order to accommodate a new design? Or letting go of the need for what we’ve come to think of as perfection in order to create a solid foundation that can withstand redesigns in the future. What is more important, to save a few kilobytes now, or hours and hours of time recoding down the road?

Imagine…

You are charged with implementing a design overhaul for a site you have never worked on before. You have the PSDs in hand as you go to look under the hood of this site. You prepare yourself for the nightmare of someone else’s convoluted code. However, to your astonishment, you find a site that is so well coded with semantic markup, flexible IDs and classes, plenty of hooks, and real content hidden behind any Flash or descriptive images that you do not have to work with the XHTML at all. No dreadful find and replace mishaps. No recoding all the pages from scratch. Just a Zen-Garden-esque experience. PSDs, a style sheet, and you.

Let’s live up to the hype.

By Mani Sheriar
Source: www.thinkvitamin.com