While I nod my head in agreement to recent thoughts on validation and it’s place as a piece of the web design puzzle, I’m reminded of where and when I personally think that it can make the difference.
Why the heck is the footer crammed all the way over in the right column?
A mildly ficticious scenario, but one that is certainly plausible. The display issue could be anything really. You’ve poured over every last CSS declaration, searching for the key that’s throwing off the entire design. Hours may go by after trial and error, removing code, adding it back it, etc.
Then you throw it through the validator.
Line 326, column 6: end tag for “div” omitted…
Of course. All better now.
I’m merely illustrating a point — that (for me personally) validation is key as part of the building process. Checking to make sure my “i”s are dotted and “t”s are crossed eliminates several possible culprits if I’m running into display issues. If I know the code is plumb and square, I can at least move on to other investigations. It doesn’t solve everything, but a solid foundation keeps some of the guesswork at bay.
There are other reasons for validation of course — reasons that may or may not make 100% sense depending on the (approximately) 6,593 factors that go into an average web site. A singular person may not have complete control over all of the code that makes up an entire site. If a team is involved — it takes everyone to want validation in order to make it happen. Tools and feeds and software must be part of the game. Editors, managers and developers have have to understand the importance of forward compatibility and a higher threshold of consistent device and browser support. But oftentimes, these things (or people) are out of our direct control. This is what makes validation hard.
So I try to stay valid as much as possible — and the building process is certainly a convenient time and place where it happens the most.
Inconsistent Consistency
It also relates to another topic that I’ve been thinking about lately. That basic validation appears to be more important when using CSS layouts, as opposed to old-school methods. I don’t have any solid research to back any of this up right now, but hear me out.
In the past, when all of the presentation was tied in directly with the content (read: nested table layouts), browsers were extremely forgiving. Forget (perhaps purposely) to close those <td> elements? Most browsers wouldn’t care and would render your intentions without any problems. This led to all sorts of bad habits. I guess we could place part of the blame on the browser…
Anyhow, forget to close <div> or <ul> elements while implementing a complex CSS-based layout and I believe most browsers won’t be as forgiving. More importantly I think the results will be extemely varied depending on the browser.
I’m certainly not referring to unescaped ampersands or other small details that could be out of the site builder’s control — but I believe basic validation on the framework of a site is crucial when working heavily in CSS.
Dribbble What are you working on? 
Instapaper Icon design 
Sass For Web Designers Paperback + eBook A Book Apart
CSS3 For Web Designers Paperback + eBook A Book Apart
Bulletproof Web Design Third Edition New Riders 
Handcrafted CSS Book and DVD New Riders 
Web Standards Solutions Special Edition Friends of Ed
26 Comments
I totally agree. Basic validation on the major components of the site are absolutely crucial in this brave old world of CSS based design.
Don’t you just hate having some little thing like that ruin your entire day… I’ve spent hours before trying to find what I did to screw up my layout- I almost never think to validate….but i should! ;-)
I would totally have to agree. Validation is part of the design process, and is essential to the development of a well coded site.
I think it’s worth noting that browsers supported ‘tag soup’ markup because they had to — 90% of the web was (and still is!) in an appalling start in terms of markup, and sidestepping that issue with an attitude of ‘Can’t parse, won’t parse’ was commercial suicide.
And also, browser forgiveness with CSS-P will come in time, inevitably, although I don’t want it to. With a ‘draconian’ attitue (to use a term applied to XML error handling, which is very related), coders are forced to make well-formed code.
Agree completely. It seems like a no-brainer now, but it can be tough to sell. I run my markup through validation before I ever begin to style it, then validate the whole schmere again before publishing to catch any glitches that may have crept into the markup as I tweaked style.
Validation during the design process is very important, and makes debugging easier. But creating valid code is not the difficult part, keeping a site valid is the point. The more people publish on a site, the bigger the chance the enter something invalid or structured differently that breaks your whole design.
I’m with you on this Dan. Valid Standard is must. We don’t want the web to end up with thousands of propreitary schemas and dtds, it benefits no-one, and confuses everyone! All coders should code the same. All Browsers should render code the same. But Wait won’t that make the web a bit dull? well not really, designers design and inovate . . . Dave Shea’s garden answers that question! As for browsers, IE is the corporate omnipresent blue E on everones desktop. Everyone knows how to use it and what it does. But the inovation comes from the likes of opera and mozilla that allow users to customise their enviroments. Tabbed browsing in IE anyone??
I agree with that wholeheartedly.
When I recoded my site, I coded it as a flat page to get it working and structured. That validated.
Then I plugged it in to all the bits of custom ASP I use. Took a while to validate after that.
Then I plugged all that lot into MT and took a fair bit of time to validate but I did eventually.
Then I imported all my blogger entries and I never could get it to validate again.
Since then the code has suffered the natural entropy code does, and even the structure doesn’t quite validate.
I figure I’ll deal with getting it all to validate on the next major rebuild.
Validating the fundamentals of a site’s structure is often times the only thing that prevents me from going insane while debugging a site’s CSS.
And as you and David alluded to, browser makers learned to support invalid code. As a result, Webmonkey published an article that infamously suggested using horribly invalid code to decrease the page weight and thus speed up the load time (remember when that was a make-or-break issue?).
You’re too right. The validator is an unmissable tool. So if you code like crap, it’ll take you longer too fix it. As simple as that.
And starting a layout in .html (or flat, whatver suits you) is a great way too check everything before stacking it with hard to work with-php.
[Re: Webmonkey article]
Craig,
not closing certain tags is actually valid up to HTML 4.01 (e.g. p, li, tr, td, th all have optional closing tags). So the Webmonkey article was only wrong about not closing FONT and I, the rest was fine.
But fortunately, this source of error has been removed from XML and its applications (including XHTML).
I agree, Dan. Making a valid site isn’t hard, keeping it valid is.
However, it reminds me hugely of the first ‘rule’ of the CSS Crib Sheet over at Mezzoblue’s:
“When in doubt, validate.
When debugging, you may save yourself a lot of headache by simply validating your code first. Improperly-formed XHTML/CSS will cause many a layout glitch.”
Dan’s scenario has certainly happened to me a few times, especially with sites that have included footers or just really sloppy markup that I’m revising. Validation helps me get my sites working, so I’m always baffled when people ask what the benefits of validation are.
I’ve almost made validation a game — when I code smaller sites, I’ll save the validation until the very end to see how close I got on my “first” attempt. On larger sites, I can’t imagine not validating once or twice during the process.
A bit off topic… I find it helpful to view my pages without their style sheets throughout the process. This is an old trick that has made the rounds several times, but if you give your style sheets a media of “screen”, you can simply use your browser’s Print Preview function to view the unstyled markup. Easy peasy, and it shows you what alternative devices will be chewing on when visiting your site.
Right on, Dan. I once spent two hours trying to debug the CSS for a Blogger layout — only to finally think of validating the markup, and then realize one of my end-div tags didn’t include the slash. One little freakin’ character — which ended up causing 14 validation errors.
Ed: There’s also a Toggle CSS favelet that only requires one click to turn off the CSS, and one click to turn it back on. Much quicker than doing a print preview, and works in almost all modern browsers. (Safari has limited support — it will only toggle off linked style sheets, not imported.)
And then to bring it back on topic:
On that same favelets page linked above, Tantek also makes available Validate HTML and Validate CSS favelets that make validating any page you’re viewing as simple as clicking a bookmark icon.
Interesting. I’m not too standards-mad anymore but just today I finished a simple little draft for a website and at a certain point I thought: “Hey, the css-validator is broken. I know that there are errors in my css”.
Then I noticed that I just validated the nine XHTML-files and the CSS without thinking about it. It simply makes life easier.
After all these “no more advocacy/no more standards”-posts, it was good to read an entry which focusses on a real world benefit of standards and validating against them.
Very valid point indeed. I recently broke my entire layout with a typo in my global css – I had a normal bracket instead of an open-brace. Wasn’t until I fed my css through the validator that I could spot the problem and stop pulling my hair out.
Validation basically keeps us on our toes. Standards makes sense in any industry – it makes the whole process more streamlined.
side note…
one trick i’ve learned to keep the ‘unclosed html tag ghouls’ away:
</div><!-- END div.class or div#id -->i (usually) add that oneline comment to every div i make as i make ‘em. it really helps when you get to the end of your document and you’ve got 4-5 closing div tags – unsure which is for what. i’m sure that habit has saved me tons of headaches.
Dan, I totally agree. I especially agree with Daniel B. Using comments on DIVs comes in handy when you have DIVs in DIVs in DIVs. I don’t use tabs to structure my html except for the main content, so labeling div’s comes in handy.
I’ve found that the more complicated the layout *before* you start testing for validation, the harder it is to validate in the end. Exceptions apply of course. But, it’s always a smart idea to validate at *every* single step of the way.
Am I the one who uses a wysiwyg editor for coding (GoLive)? Progam is far from perfect so I handcode, but I can check markup validity for XHTML every second with software. It also has a great CSS editor. It really helps to avoid simple human errors and enables to really focus on problem solving of layout inconstancies across browsers than on error seeking.
Validation was very useful in a web app project I recently completed. Improperly nested HTML code coming in from a database was breaking the design on certain browsers, and validation quickly and painlessly identified the errors without any trial and error or other inefficient debuging techniques. I’d guess it probably saved 4-8 hours of development time.
Don’t fear the validator, it is your friend! ;-)
I’m niether a designer nor a developer (though I play at both, on occasion). I’m finishing up a site for a non-profit organization (copying an existing site for another branch of the same org), and opted to rebuild it with a css-based layout, learning as I went. The validator was a godsend for translating what I learned from sites like this one into a finished product.
A fine article. A good way to stay valid is to do content negotiation to optionally serve your pages as XHTML 1.1 with media type
application/xhtml+xml. Gecko-based browsers will choke on any missing tags that cause the document not to be valid XML. It’s instantly pointed out coding errors on my site on numerous occasions.While I nod my head in agreement to recent thoughts on validation and it’s place…
But what about valid apostrophe usage?!
;-)From a programmer’s point-of-view:
Nice tale. I personally feel that there are two types of validation: syntax and type. End tags, entities, and other kinds of sugar are problems of syntax. Validation of these kind of rules are important so programs understand how to interpret your code. That’s why XML proved so much more successful compared with SGML (simpler syntax). And that’s the kind of validation your post is about.
The second type of validation is of type or meaning (or “cast” in programming lingo). In some (most) programming languages, adding a string and an integer will not validate (and give you an error). With markup, you could say that the names of elements and attributes, and their values are things that could be validated. This type of validation often isn’t really necessary as long as intelligent fallback rules are implemented. For instance, a dynamic language might turn an integer into a string so it could be added to another string. Or an HTTP parser might ignore a rule it doesn’t understand without producing a fatal error. Or the closing p tag could be added when it must be included (i.e. before block-level elements following an opening p tag). These types of errors are less serious and often not necessary and actually decrease the performance of developers or writers (tho it’s the bane of grammar-nazis). You certainly should sweat such small stuff.
P.S. The examples involving HTTP and integer/string conversion are not my original ideas. Other, more intelligent people blogged them first: I simply stole them and forgot for whom to attribute credit. Please forgive me and correct me if necessary.
I agree that validation is important throughout markup development. The barrier that seems to prevent me from validating more often is that my coding is done on a local computer or on development domain names that are unaccessble to the online validation scripts. This means that to validate I have to upload scripts to a live server, which in some cases isn’t practical if there’s databases and scripts that are all setup locally but I’m not ready to put live. Maybe I’m being lazy, but it’d be nice to know if there’s any tools I could use to validate an XHTML/CSS document on a server that is closed off from the Internet.
Validation for me is automatic. I also convert any FONTs to use CSS. I use the free HTMLkit from chami.com, and it’s one button to validate (and pretty print and convert FONTs and convert to XHTML) and two clicks to copy it back to the source file.
Once I converted over to using CSS, I found that the code had improved significantly, and I use the validator mentioned all the time. I wish that Frontpage, DreamWeaver, et al., would incorporate validation more effectively. I could never understand why a Microsoft product can’t seem to produce compliant code.