Validation, Moderation, Constipation
Validation matters. No it doesn’t. Validation is hard. No it isn’t. Standards are flexible. No they’re not. Does this conversation sound familiar?
While variations of the debate over the ease and importance of following the standards to the letter have been flying around for years, the coming summer months appear to be heating up the arguments once more.
There’s a cross-site conversation about validation happening at the moment, and you may have seen it in places I haven’t. On this site anyway, a seemingly innocuous opinion piece from last week calling for moderation and sensibility saw the discussion fly completely off the rails and devolve into a sordid display of finger pointing and blame. A misunderstanding is occuring between two loosely-defined groups that is resulting in unnecessary hard feelings.
(I’m going to generalize here and label everyone as a ‘designer’ or a ‘coder’ to illustrate my point; recognize these statements are general trends; exceptions exist, and there are people who are both or neither.)
When standards-conscious designers validate their XHTML and CSS templates, everything is nicely compliant up until the point where they start tying in the necessary automated systems like ad software, CMSes, or e-commerce apps. The tools then get in the way and code is needed to fix validation, but a lot of designers don’t code. Because the issue is technically out of their hands, they look for ways to justify the validation failure and avoid responsibility.
Coders that care about standards have fixes for the problems they experience with software. It’s relatively easy for a coder to automatically escape ampersands in generated code; at the very least, they know how to Google the fixes. At best, they can scrub all automated output, fix errors, and tune their HTML to a degree most designers would only dream of. And many of these coders look at the designer’s failure to duplicate their success as laziness or worse, without realizing that a designer’s skill set simply does not extend to the world of fixing code output.
This divide is illustrated nicely in Mike Davidson’s article which I linked yesterday. Mike is looking for reasons not to validate because he deals with these types of systems, and fixing them is a Herculean task he doesn’t have the resources for. The fun begins when Steve Champeon pokes his head in (comment 15) and attacks Mike’s arguments on firm logical grounds. But Steve throws in a telltale sign that he has unrealistic expectations of Mike, by referencing “the slacker ethic” and stopping just this side of calling Mike lazy.
There are two truths here. One, people of all different backgrounds and talent levels are creating content for the web. Two, there’s still a remarkable assumption that one who does a certain job for the web does all jobs for the web, which even comes from colleagues who should know better. That the assumption exists is true; the assumption itself is suspect. Everyone who survived the past 5 years of economic downturn did so by diversifying, but specialties still exist simply due to the massive variety of possible skills that no human could master in one lifetime. I don’t expect a coder to know the first thing about monitor colour profiles or typography; it’s great if they do, but I don’t expect it. Likewise, a coder should not assume a designer knows how to deal with data, or fix validation errors using code.
Okay, whew, we’re through the build up. That wasn’t even the part I wanted to write. This is:
Can we all just shut up and start listening to each other please?
Designers: the coders are trying to tell you that there are ways to encode those ampersands and validate things like comments, do it with minimal time investment, and make it happen automatically.
Coders: the designers are trying to tell you they don’t have the skills to implement these methods and they need guidance here.
During the raging debate on this site last week, two contenders — Jacques Distler and D. Keith Robinson — both contributed their share of the blows, but after the dust settled they ended up working together to solve Keith’s problems. A coder willing to share his or her experience is worth 20 coders who will point out a problem without suggesting a fix. A designer willing to accept help instead of sweep the problem under the rug and justify it with spurious logic is golden.
What we need is to start working together like this on a larger scale. You’ve gone to lengths to programmatically fix improperly nested tags? Great, write it up. You have a killer PHP function for parsing out raw ampersands that can be copied and pasted into a site-wide header? Perfect, share it. You can make a bad tool better? Do it! We don’t have to keep re-inventing the wheel for every new site, we can build common code bases that make validation painless and share them.
A knowledge base of tricks and tips for dealing with bad HTML would go a long way if it’s easily understandable by the non-technical, or even better, copy and pastable. Arguing is a good way to waste time, but if you really want to change the way someone works, show someone how it can be done. Don’t leave it up to them.
- Comment Sanitation — PHP solution. Built for weblog comments, useful for more.
- Tidying up your HTML with PHP — PHP5 solution that builds on HTML Tidy
- HTML Syntax Checker — PHP solution. More like a sanitzer, it will additionally strip out unwanted markup to keep output clean and more structural.
- UTF-8 Convertor — PHP solution. Unicode character cause validation problems if not properly accounted for.