Here we have two well-known standardistas, both of whom have done (and will do) more for the adoption of standards than this author ever will. Yet both have different takes on what role validation plays in designing for the web. In fact, they perfectly represent the division that exists between standards advocates today. You probably find yourself taking one of two positions on validation:
- You take a hardline stance, rightly stating that if we fail to follow the conventions of a language, then we’ve produced something altogether different and, well, invalid.
- You take a pragmatic view, rightly stating that the invalid code generated by broken tools and third-party code shouldn’t negate one’s overall commitment to web standards.
So if both views are right, where does that leave us?
The problem at hand#section1
We can all agree that the realities of the web make it hard to build a standards-compliant site. Once the client’s CMS, outdated WYSIWYG editors, and third-party advertising code have finished with once-valid markup, things begin to look ever-so-ugly under the hood; this leads many to suggest, like Bowman, that an insistence on validation is at odds with commercial web design. Given that most of these invalid sites look fine in a browser, the amount of time and money required to produce perfectly valid final code seems not only prohibitive, but pointless.
Valid markup has become equated with two things nobody wants: impracticality and implausibility.
Refining the message#section2
If it weren’t for the early days of standards advocacy, for sites like the CSS Zen Garden, Wired News, or Fast Company, we wouldn’t be as far along as we currently are; heck, I’d probably still be a self-hating
spacer.gif slinger. Despite those successes, our fractured take on validation stems partly from the wonderful evangelism that got us here.
Whenever I conduct a training session, I poll the room to see why the audience uses or plans to use web standards. The responses typically read like a doctrine that my generation of web designers have been raised on. Namely, that building with web standards can…
- shorten development cycles, as we no longer have to slog through through six layers of nested tables to build site templates.
- lower maintenance costs, as the CSS Zen Garden showed us.
- decrease page weight, which in turn reduces page load times and dramatically lowers bandwidth costs (we’ve Mike Davidson’s excellent <!-- 403 MAR2013 -->ESPN.com interview<!-- --> to thank for those metrics).
These are, I think, the “sexier” benefits of web standards, the bulletpoints we’d use to sell prospective clients on CSS-/XHTML-driven designs. And with good reason: these are all excellent, compelling points. No sales pitch should leave home without ’em.
Noticeably absent from the list is any mention of why we should adopt standards, or what that process actually entails. I mean, I’m sure we can list benefits of producing valid code, such as:
- A proven increase in a site’s accessibility,
- The promise of device independence,
- The presence of a metric against which an individual or a team’s production can be measured, and
- The knowledge that your site is future-proof, displaying in any standards-compliant browser yet to be invented.
But the sum total of those points doesn’t exactly scream “compelling business case.” When you’re speaking to a mid-level marketing executive about standards, which would you rather lead with: saving terabytes of bandwidth, or investing in device independence?
Yeah. That’s what I did, too.
Yet while the benefits of valid code may not be glamorous, we can—and should—talk about them. Validation isn’t an end result or a final deliverable; it’s an ongoing process that continues long after a site launches. If we don’t put the proper tools and commitment in place, our work will start looking like a late ‘90s throwback, and if we don’t provide guidance and education on validation, the polished, perfect pages we produced will be snapped into software that’ll produce tag soup in seconds flat.
So how can we speak about validation in a way that’s compelling to our clients?
The hidden cost#section3
Validation might not have been the sexiest selling point for standards, but it does have very real fiscal benefits. In the past couple years of running my own practice, I’ve become slightly obsessive about tracking my time, especially when it’s spent dealing with bug reports. When an issue comes in, I note the error and the account, and start the timer. Once it’s resolved, I note the cause, stop the timer, and move on.
Toward the end of my first year in business, I noticed that more and more of my time was spent working around invalid code. Layout issues that would have been trivial to fix in a valid, error-free template would take significantly longer to debug in a live page that had a few hundred validation errors. It was a matter of figuring out which parts of the page weren’t causing the errors, so I could focus on fixing the problematic section. But when the page’s markup has three or four hundred validation errors, this process quickly becomes a time sink. A necessary one, but a sink nonetheless.
So by year’s end, I found that approximately fifteen percent of my time was spent mired in invalid code. As an independent designer/developer/something, I’m grateful for all the work my clients send me. Still, what if I was a salaried employee? If IT departments conducted a similar audit, I’m confident they’d find similar numbers. And this kind of auditing needs to happen. Invalid sites may look the same as those built on a foundation of valid, well-formed code, but in my experience, they invariably cost more to maintain. This is the silent weight of invalid code, a hidden cost we don’t discuss nearly enough.
None of this changes the here and now. To be honest, the pragmatists are right: that for the most part, validation and commercial web design are polar opposites. But the tools are evolving to the point where we can begin moving beyond validation as a roadblock, and CMSes like WordPress and Slashcode are dedicated to producing standards-compliant code; visual editors such as Dreamweaver and (more recently) Microsoft Expression Web almost stubbornly refuse to produce invalid markup. So where do we go from here?
Pitch process, not code#section5
In recent months, I’ve been relearning how to sell standards. I still touch on the exciting bits (the lighter pages, the lower maintenance costs, and so on), but I don’t shy away from selling validation’s role in unlocking the real savings of web standards. And it’s been an easier sell than I’ve thought: once you’ve shown a client how standards can improve their sites’ accessibility, keep it future-proof and device independent, and lower maintenance costs, they’re usually ready to listen.
And that’s where the real conversation begins. By considering your client’s production workflow and the software that supports it, you and your client will be better able to identify what could break your joint commitment to standards—and as a result, they’ll be better able to fix these issues themselves.
Shop smart: shop standards#section6
Companies like Adobe and Microsoft have recognized the growing market for standards compliance, and openly tout their products’ W3C-friendliness in the sales material. But despite that silver lining, most CMS tools and online advertising companies are spewing out code that would make Netscape 3 proud.
This is where the lone consumer can move mountains. When meeting with a prospective vendor, our clients need to ask if the product is standards-compliant, much as they might ask if an ad serving solution provides targeting information, or if a CMS is J2EE compliant. Standards should be an equally weighted part of any decision-making process—and if we remind our clients of the financial benefits of validation, it will be.
Same sandbox, same struggles#section7
But in all honesty, the real work begins with us. Regardless of whether we find validation impractical or imperative, the infighting in the standards community is the biggest obstacle to real progress. Instead of trying to understand what factors make both sides agitated, we’ve vilified the people on the other side of the argument. We need to identify what’s making 100% validation so expensive and difficult, and work on removing those factors.
As our contribution to that effort, we’ll be discussing common validation killers and ways around them in an upcoming A List Apart article. You can contribute by using this article’s forum to bring up common obstacles to validation and the workarounds or process changes you’ve used to get past them.
Samuel Johnson once said, “Where there is no difficulty there is no praise.” Personally, I think that Sam would’ve sung a different tune three minutes into debugging his first CSS layout, but the man has a point: we can’t fall prey to complacency.
In a perfect world, clumsy software and bad workflows wouldn’t break our code, and validation would just happen. But until I also get that magical flying pony I asked for, we’ve got some work to do. After all, true standards compliance is only as impractical or implausible as we make it. Given how far we’ve come in the past few years, this next challenge seems like a trivial one indeed.
Let’s get to work.