Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

The Real World

September 24, 2003

Looking for some well crafted, beautifully designed CSS-based sites for inspiration? Look no further than the portfolio of local Vancouver boys twothirty media.


You’ll note, as you start poking through the source code, that most of these contain the odd table or two. You’ll also notice that most come close to validation, but don’t quite succeed.

These are real-world examples. Waxing theoretical about the benefits of pure and valid markup is fine, but when crunch time comes this is almost always the reality. Wired and ESPN do not validate. Cingular was never perfect, and is quite a mess now.

What can be said for the tables? Transitional layouts are still necessary today, given project requirements. Some visual effects cannot work reliably between the major browsers. Others cannot be done without CSS3. It’s fun to think of a day when all browsers everywhere will handle every layout exactly the same. It’s also fun to think of a day when we’ll have flying cars and full meals in convenient pill format.

As has been noted elsewhere, we the people who are doing this for a paycheque face reality, not theory. When push comes to shove, we make the choices that work. This is not always consistent with the “right” choice.

Commercial web design will continue to be about compromise. Nine times out of ten, the more effective use of the client’s dollar goes toward building and refining content over validating every last tag. Not to say that the two are incompatible, but between spending $500 on purifying their source or creating additional ads for off-site promotion, guess which most clients perceive as the most value for that money?

This is no excuse not to strive for the end goal of a compliant site. But it is a polite reminder to those who would find fault in others who, through factors they have no control over, can only go 95% of the way.

Theory is nice, in theory. But providing the best solution involves knowing that sometimes, it’s okay to break the rules.

Reader Comments

Shaun says:
September 24, 01h

Funny, I just went for a walk around the block to ease my frustration at working in a place where getting something done period seems to be of greater import than getting something done right. Your consolation is quite apropos. Cheers Dave.

Jai says:
September 24, 01h

I hear ya on this one, Dave. Though tableless structure is a spectacular goal, and one to strive for, sometimes that’s just not practical. The site that I am commissioned to oversee was coded by a monkey before me, and the site is huge with constant content updates. Then, to make matters worse, the content management system that is going in in a month is based on tabled layouts, giving the desigers no access to head, css, or other important table killing tags. But do I “sin in the eyes of the almighty web standards deity” for a paycheck? Heck yeah. I wish there was another way, but sometimes, as you noted, it just isn’t.

P.S. - glad your site is back up. Looks good to me. I wonder what’s with that “every 4th refresh” thing. That’s just flat out weird…

Keith says:
September 24, 01h

Damn, those are some nice looking sites. Oh and Shaun, your point about “getting something done period” is SOOO on the money.

September 24, 01h

no…i’d rather get drunk and dream of a world where xhtml2.0 is a ubiquitous reality and css rendering is consistent across all browsers… ;)

yup, when it comes to real life, we’ve all got to make sacrifices. transitional layouts with one or two (non-nested) tables is ok in most situations…and in future the content can still be extracted/munged/transformed into pure table-less code without too much hassle (which can’t always be said of tagsoup).

heck, if it pays my bills, i’ll roll over and do a 100% flash site held together in a nested table, if that’s what it takes…

Didier Hilhorst says:
September 24, 02h

Spot on.

By the way let us not forget that the W3C drafts recommendations. We are not talking about the law here where (strict) rules should be followed to avoid punishment.

There is no right or wrong in webdesign (as such). However there is good and bad. We all know by now that huge bandwidth sucking flash intro’s with bad techno music are a big no-no. We also know that we will have to drop tables for presentation some time in the future (except for tabular data). Again these examples are not wrong as such, they are just not a very good idea.

Let us cheer at those that implement CSS-based design into commercial projects instead of flaming them for not following W3C recommendations à la lettre. In the end the real-world is indeed more complex.

September 24, 02h


These are some nice looking websites…

meat says:
September 24, 02h

man, nice work but that last site ( ) has a nav bar that looks an awful lot like the nav (well, before their mx 2004 upgrade)…

queenB says:
September 24, 03h

amen. the fundamentalists always ruin the fun.

John says:
September 24, 05h

Re “meat” saying that the Eos menu is like some older Macromedia menu. !!

In fact the menu is based on the “ypSlideOutMenu” by Aaron at

The site itself is a breath of fresh air.



September 24, 07h

Beautiful article. I’ve been dealing with the eventual compromise between elegant standards following code and just making things work. CSS is great and all, I love it to death, but it’s much like giving up my working peice of junk car for a brand new mercedes that only has two tires and I have to drive with my feet.

Michael says:
September 25, 01h

Look for logos with blue/navy circles or half circles. You’ll find millions. See EDS and Express-Scripts. How many logo’s out there look like a representation of Saturn (which mimics the circle/half circle premise)? Most logos out there are generic by nature to make them easily remembered by the masses. Plus there’s just so many ideas out there and it’s pretty easy to duplicate an idea that someone else had.

Eric says:
September 25, 01h

Well, lots of true statements here, but I have to admit that most of the time not having valid code is mostly a matter of laziness and lack of familiarity. God knows I’ve done my share of non-validating pages but I admit that it’s usually because I have run out of steam by the end of a project and I just don’t really care that much. Whenever I have set about making valid pages, I almost always accomplish it.

paul says:
September 25, 03h

eric, i completely disagree that it’s because of laziness or lack of familiarity. i consider myself meticulous when coding sites, and i’m quite knowledgable with standards-code. here are a few reasons why most of the sites dave listed don’t validate:

- CMS issues - sometimes my company can’t pick the CMS a client uses, and the CMS we have to use doesn’t spit out proper code. this happens in the majority of the examples above.

- links - some of the links on those sites have chrs in them that cause the validator to output an error. since i can’t change the links on external sites (i.e. amazon, referral programs, etc), nothing can be done about that.

- form submissions that submit to external sites that contain invalid code. again, since the form submits to registrar, there’s nothing we can do about the code being invalid.

- external scripts, like stats trackers with invalid code. again, it’s an external force that can’t be changed.

- another big one is clients that do minor edits via frontpage/dreamweaver/(insert crappy wysiwyg) editor here. once we’ve handed a site off to a client on their servers, we’re not responsible for it validating forever, unless we get paid to.

and those are just a few reasons, there are many, many others.

September 25, 04h

Paul, you can make your links validate by encoding them properly. You don’t need to change the URL; it just needs to be encoded the like any other text in an HTML/XHTML document (e.g. change & to &).

Similarly, most of the stats scripts I’ve seen can be made to validate just by escaping characters correctly (generally by adding backslashes to special characters in Javascript).

I don’t understand why forms to external sites can’t be made into valid HTML. As long as the form fields and values are still the same, what prevents you from correcting errors in the markup?

This leaves CMS systems and client editing, which I agree have no good solutions.

September 25, 09h

This is so accurate. When reading some html newsgroups, people get on their high horse and preach how things MUST be done and I wonder if they’ve ever had to work in a corporate environment. Comprimise is everything but it’s nice to see things heading in the right direction. On a side note, anyone notice that the logo for Firewhite is very close to Watchfire ( )?

Sara says:
September 25, 11h

When I was learning basic CSS I became so frustrated when I couldn’t build table-less sites that worked in every major browser/platform.

Then I picked through the portfolios of the “CSS gurus” and discovered they wrote table sites. If they can’t do without layout tables then I shouldn’t feel guilty about adding a table now and then.

Remember folks, table-less CSS is the IDEAL. If possible, use it, but if your boss has a gun to your head and you have only minutes to spare, then use tables.

paul says:
September 25, 12h

jonathan: i think stylized flames in general are very popular, and i could probably find a bunch of sites with similar logos. my company didn’t design it though, so i don’t know. it looks more like a similar style than a copy though.

James N Pope says:
September 26, 08h

Here’s another real-world example for you: Nice big complex site that looks gorgeous. Couldn’t possibly validate as XHTML right? Well, take a look for yourself:

James N Pope says:
September 26, 08h

Almost forgot - (at least the home page) is built without a single table tag.

Eric says:
September 26, 09h

I agree that CMS systems and client editing can be bad, but I don’t include these when I say “my pages”. Sure I write those pages, but they aren’t really mine. As mentioned, links can (and should) be encoded.

Third party scripts can be changed, because they are typically done by someone you or the client is paying, and if they have some bad code, you often have leverage to fix it (at least with larger clients). If you inspect the code prior to making a commitment, you can also use this as criteria in your selection process.

haze says:
September 29, 11h

eric, i think what dave is trying to say is that the real-world projects differ from joe blow who codes his blog and makes it valid through the css validator. real-world projects are run within a budget and within a deadline. blogs dont have a budget or timeline.

it’d be great to get things perfect, but projects are like term papers. you can try to make the paper as perfect as possible, but the night before the deadline, youve got to make a decision on either submitting a late-yet-perfect project or an on-time-yet-not-so-perfect project.