A Good Website Requires 1 3/4 Cups of XHTML
I recently spoke to a group of web design students at a local college. My talk primarily focused on content management and JavaScript frameworks but I also talked in broad terms about our philosophy when creating XHTML/CSS layouts. I would argue there is no perfect recipe for laying out a website. Everyone seems to have their own methodology, so here is a quick description of mine:
There are a number of ways a webpage could be laid out. You could use tables and inline formatting. You could even use the tag if you were really feeling crazy. On the opposite end of the spectrum you could write a minimalist XHTML / CSS infrastructure going so far as trying to eliminate or nearly eliminate the use of id and class selectors. In the end, both have the potential get you the same result. The two sites may look identical to the untrained eye. Both are also likely to have compatibility issues with various browsers. Both are likely to be pain to maintain in the long-term.
Our goal at Zipline is to create functional code. When laying out a webpage we look for the most efficient way to create a stable layout. To me a stable layout is one that renders the same in all major browsers, including IE6. A stable layout is also a layout that doesn’t break when it expands or contracts. Most of the websites we create are content managed. With a content managed site it is difficult to determine how much text a page ultimately may hold. The entire application from XHTML / CSS to content management code is designed to prevent the customer from inadvertently creating something that blows apart the layout. Another important goal with each layout is to create something that is easily maintainable. Some minimalist XHTML/CSS layouts are very difficult to follow and maintain. This is especially true when the developer working on the project may rotate. If it takes us 3 times as long to make a change either we must eat that cost, or pass it on to the customer, either way, nobody wins.
If a layout requires a couple extra elements to be stable we will certainly add them in even if a less stable version could be achieved with less mark-up. We very, very, rarely use hacks. In fact, I cannot even tell you a Zipline site that uses a hack, even for IE6. Don’t get me wrong, we’re not out creating nasty bloated table based layouts. We’re using clean XHTML and CSS, we’re just trying to do it as efficiently as economically possible without compromising the stability of the website. We have been fortunate enough to look under the hood of many sites, developed by many different developers. I have seen the good, the bad, and the ugly. From these we have extracted a methodology that works really great for us, and renders the same in all browsers… without hacks. As I always say, hacks are for hacks.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Whoops, somebody didn’t escape the brackets for in the text.