Why is it so important to validate?

If my site looks good in all the main broswers why does it matter if it validates?

 

You answered it yourself already but there's these points to remember:

A page that doesn't validate is often a page that isn't accessible to those without good eyesight or hearing. You can actually get sued in some countries for not offering access to those physically 'challenged'.

If a page validates, you will know it works in almost all browsers and almost all spiders can handle it. If it doesn't, your probably don't know to what degree. Is it really broken or just not conform the latest standards but otherwise fine? By validating you know...

Also, by spending weeks on making sure every page validates, you have a good excuse for why you haven't made any money yet with your site.

 

Some useful information here on References on Web Accessibility.


http://www.w3.org/WAI/References/QuickTips/Overview.php
http://www.w3.org/WAI/References/

 

IMO it doesn't matter much. Validation can pick up some errors you might otherwise miss though like missing table tags.

 

how about SEO? I heard google dislike code with mistake

 

I learn something new every day. Which countries are you referring to?

 

Basically exactly what T0PS3O said just cos it looks fine to you does not mean it looks fine to everybody or everything.

Even if your site is valid though it still dont mean it is done correctly semanticwise though, there are loads of things that the validator dont cover, but if it validates it is a good indication that the person who coded the page does know how to code pages.

Semantic article

EDIT

But about what TOPS30 said about spending weeks making it valid, that is just it though you should not have to do anything extra to make your site valid, you should be coding you page correctly from the start anyways. Yeah fair enough you may get the odd thing you missed but generaly you should not have to do anything extra at all to make your pages valid or your doing something wrong.

 

ResaleBroker: The UK is one such place where blind people can theoretically sue you successfully if indeed you don't have alt text or other stuff that text browsers read out. To my knowledge, no one has been sued but I do expect a couple of suits with big names to set an example. It's now regarded just like a supermarket wouldn't have an access ramp for wheelchair users.

Johneva: If you indeed write your own pages from scratch, you should indeed do it properly from the word go. However, if you use a ready made package such as osCommerce or any other popular piece of software that is years old, chances are it won't ever validate unless you rewrite it form scratch.

 

Well yeah true true.

 

In which case, you're allowed to use a transitional or loose DTD. If the page won't pass then, you might want to be looking into other solutions.

The big problem with invalid html markup is that you're at the mercy of the browsers' fault tolerance routines, and how each browser 'guesses' at what your markup really meant. Further, if you need to alter or otherwise maintain the page, your changes may not have the expected results. Debugging in an invalid page can be a real adventure when it's not being a more prosaic PITA.

cheers,

gary

 

Validation is a case of taking a little time up front to save yourself a lot of time in the long run. Sure, you can keep testing things in all the browsers you have and spending time changing things to work in them (if you actually have access Safari or Konqueror or the like). Sure, it seems like trouble at first to fix your errors. After you do it a few times, however, you begin to learn and don't make the same mistakes so validation is no longer a difficult process. Once you're writing pages that validate, you no longer need to worry much about checking all the browsers.

I went two years without access to Internet Explorer (Linux-only), but thanks to keeping the HTML valid things still looked the same in each browser when I finally checked. That's not to say it isn't helpful to check different browsers for some rendering oddities (I've noticed Firefox tends to differ from Opera and IE when you're dealing with div floats for example), but with valid HTML you can make it a less pressing issue and much easier to fix when you do find a difference.

Don't forget that if your page is only working accidentally (which is what it means if it's invalid) you might see it working in IE 6 but not in IE 7 or IE 5, or working in FF 1.5 but not FF 2 or FF 1, so far as you know. There's no point in taking a risk on something that isn't officially supported.

 

Some time ago I had a client tweak my ear over validations. He was told by a competitor web firm that the site we developed for him did not fully validate.
So naturally I had to explain to my well-meaning client the following email letter:

Validation Isn’t Everything

Like it or not, industry jargon often coughs up terms that become buzzwords. When this occurs—and it occurs across the board; web development is no exception—the terms can become diluted, even ambiguous. Two such terms lately include “validation” and “web standards.” To be clear, the W3C provides specifications and recommendations, not mandates. In a rigorous sense, it can be argued that true web standards do not exist: they are a myth. Scary word! But don’t be alarmed. Don’t confuse myth with falsehood. So-called “web standards” are a myth in the sense that they describe an oft-repeated ideology that strives to establish popular convention.

Thinking optimistically, we might call these an ever-evolving ideal, something we as a community are still working toward perfecting. What we have, at present, are de facto guidelines, principles that serve an objective without being legally enforceable.

If a house’s wiring and electrical components are not UL-listed, the home inspector may refuse to issue occupancy permits. When ISO compliance isn’t met, products don’t ship. These are high stakes. On the other hand, in the face of invalid web markup, websites march on. The overwhelming majorities of surfers don’t bat an eyelash and don’t need to.

Provided the developer has written functional markup, failure to meet W3C validation means nothing more than the fact that a document contains something that is either not in the specification or is in disagreement with the specification. Invalid markup is therefore not necessarily in violation of anything. These strong words—“invalid,” “violation”—may pack a punch to the layman, but in context of the web developer’s lexicon, they reflect markup that may be an addition to the specification or something the validator simply doesn’t recognize. Certain JavaScript that is universally understood by user agents, for example, does not appear in the HTML specifications.

Let’s not misunderstand. Poorly formed HTML can be a hassle to update. It may be a factor in search engine optimization (whose “standards” change often, to the chagrin of SEO subject matter experts). In some cases, it can cause content to load slowly (or appear to load slowly). Validators are great for quickly spot-checking possible deal-breaker gaffes among copious volumes of markup. But validators are servants, not masters. W3C badges are effectively academic badges of honor. Such validation is an admirable enough goal, but is not always worth the return on investment in a production environment. Far more important is to ensure that markup is efficiently written.

Let’s see if the big boys agree.

Google and Yahoo! handle some of the thickest traffic on the market. As of this writing, neither site complies with the W3C validator. How about heavy-hitters CNET and eBay? Failed. Adobe’s and Macromedia’s websites? Failed. What about php.net and python.org? These are the home bases of open-source developers who themselves rely on evolving quasi-authorities like the W3C … but no; these sites fail, as well. How about netscape.com? Staffs of Netscape Communications Corp. are members the W3C, after all, and Netscape is responsible for JavaScript, one of the worlds’s most widely used client side technologies. Yet their site does not comply. Surely useit.com, the site of the esteemed usability guru, Jacob Nielson, is compliant. Surely! Guess again.

W3C validation is not the web developer’s Holy Grail. Validation does not guarantee a site will look the same from platform to platform, from browser to browser. Validation does not assure that markup is efficiently written or adheres to a given entity’s assessment of best practices. What it means is that the developer has coded a functional document and used no markup in addition to that specified by the guidelines. Wearing suspenders in addition to a belt isn’t illegal, it’s just … extra. No harm in that, is there?

 

Well, if you can't dazzle'em with brilliance, baffle'em with bullshit.

That browsers have a tremendous degree of fault tolerance does not excuse the use of invalid markup for new sites. Many of the sites you mentioned have an unbelievable inventory of pre-standard pages. Bringing them up to date, and altering the template they use will be a very expensive proposition, though some have done it. The Register runs valid markup, for one.

Saying that all the other kids are playing in the street does not justify your doing so.

But let's look at Useit.com which you so proudly hailed as an example of invalid markup. A trip to the validator will indicate eight errors. So what are they?

• Two are for the use of the 'name' attribute. Yep, that's an error. Should be 'id' according to html4.01. However, all browsers recognize 'name', while many older browsers do not recognize 'id'. If you're trying to ensure access for older browsers, you must use 'name'. It would have been a Good Thing to redundantly use 'id', but 'name' would have still triggered an error. But, is it really, in this usage? Nielsen stresses backward compatibility more than I would, so I'd not count that an error. Plus, it is a transitional DTD, so it should be accepted.
  
• Three are for not using the required 'type' attribute for the script element. Useit.com uses the 'language' attribute which is deprecated in html4.01. Let me quote from Dynamic HTML by Danny Goodman:
  • … but it has been so widely used since the first days of scriptable browsers that its use and support will continue for a long time to come. Moreover, it is so far the only accepted way to convey the JavaScript version for the script block. (emphasis added)
  Again, this is a transitional DTD, not strict.
  
• Three errors are validator errors, not document errors. The validator is trying to parse the javascript and showing errors that don't exist.

Unless one wants to be anal about this, the page is ok. Technically you could fault the lack of the 'type' attribute. With a transitional DTD, that would be pushing things.

But, it was a good job of blowing smoke. Your client should have been well and truly befuddled.

cheers,

gary

 

But, the point was/is, even the largest sites don't worry about having a validated site.
I try to keep out any major errors, but the little stuff just doesn't seem worth sweating over.

 

I dont worry about it either but my sites are valid cos I write valid code.

As I say it should not be any extra work cos you should be able to code your pages properly anyways.

The larger sites normally have not worried about being valid cos the sites are so old and it would take so much time to redo the whole site it is just not worth it yet.

But soon they will have to if they want there site to work for everybody because things are changing not everybody use IE6 anymore.

Anyways just cos they work for a big company dont mean they are the best designers/developers around.

 

johneva: good points. I owe you some rep after I spread the love. Can I get a proxy?

Bryan G: There's no sane reason not to write valid markup. HTML is not that hard where the well-formedness (validity) is concerned. The more difficult aspects are the semantics and structure, which don't impact upon validity.

cheers,

gary

 

bjraines:
You asked why is it so important to validate. You have received many informative responses. However, I would like to make a little contribution gathered from my own experience. Sometimes the page looks great, but it has some hidden flaw, some illegal markup that the browser rendered as it could. When later you try to make a similar page, you don't get the same look because this time you didn't make that mistake. You scratch your head and don't understand what is happening. Conclusion:
if you validate your code, you know that what you get can be reproduced any time you use the same code. That is, IMHO, a reason to validate what one does.
Hope this helps.

 

Plus it makes you look like a pro!

 

Well, it's quite simple: to follow the web-standards, lol ...


P.S. -- But anyway, also check out the sources linked above to read a bit more about the various benefits of doing it (i.e. making a W3C-valid site)


tayiper

 

Personally, I think accessibility is more important. Things like alt for visually impaired visitors who utilize screen readers is of utmost importantance. It is also my understanding screen readears can navigate tables, but have difficulty with frames. Additionally, load time is important whether your code validates or not.

I am not a fancy designer myself and have myriad of validation errors but it doesn't seem to affect my ranking, so I still sleep most nights.

I believe it has importance, but isn't crucial.