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

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.

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…

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…

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.

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.

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.

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.

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.

- 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.

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 &amp;).

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.

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 (http://www.watchfire.com/ )?

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.

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.

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.

Search this site:

About This Entry:

You are reading “The Real World”, an entry posted on 24 September, 2003, to the No 1 collection. See other posts in this collection.