Do you validate your websites?

Question

I recently read a great resource by the Opera developers, entitled, "Introduction to The Web Standards Curriculum". I thought the articles put forth some good reasons why you should look at validating your website, but I realize that not everyone validates their sites, including most of the big names (Google for instance). Do you validate your sites? Have you ever had an instance where not validating your site has hurt you or your company? For you and/or your company, is validation worth the time and money? How do you evaluate its worth to your company? Do you care? And, perhaps most importantly, why or why not?

Answer 1

I validate both my HTML and CSS, because it helps with debugging display issues a lot. If your HTML is invalid, the browser has to make a "best guess" at what your HTML is supposed to do. I also find the HTML/CSS much easier to work with if it's valid. Working with broken web pages can be a pain, because adding stuff to them often makes things that worked before look suddenly break down because the browser decides it doesn't like it.

Answer 2

Yes I validate all the pages on my website. I use: http://validator.w3.org/ and I have a link to the validator at the bottom of every page on my site so I can just click on the link and validate that exact page.

Answer 3

Have you ever had an instance where not validating your site has hurt you or your company?

Not in the short term, but definitely over a longer time period, as far as maintenance is concerned.

We have had a site which has never validated, and has several layers of tables nested within tables, nested within tables, etc. It's been known to happen that a change has been required to this code which seems innocuous enough but ends up completely breaking the existing layout and requiring far more time and effort than we initially budgeted for to fix, and make sure it's correct in all supported browsers.

So for all of our current projects, we have found that it is absolutely worth the time and effort on any non-trivial webpage (more than 1 table, 1 input) to make sure that it validates.

It also makes it easier to find and fix any cross-browser display issues, and generally makes our maintenance far more manageable.

Answer 4

Nope.

I don't care what the validator says. I only care if it renders correctly in all the major browsers, and the validator doesn't check for browser errors.

Maybe someday the validator will be enough, but I'm not holding my breath.

Answer 5

For me, validation is an integral part of the website development process, much like debugging/testing is for conventional development.

Perhaps a better comparison would be applying style guides to one's code. There are tools – FxCop for .NET – that verify conformance to programming guidelines. Many enterprises find it important to have this verification as a hard requirement. But I believe validating HTML is even more important because it gives a more direct feedback: If the validator detects an error in the website, this is almost always a real, unintentional error. Unfortunately, such errors often go undetected for a very long time. Then you change something (seemingly) unrelated and everything breaks down.

Cross-browser HTML design is complicated enough as it is. I believe in getting all the help that I can. … apart from all the other arguments that speak for producing conforming HTML code.

Furthermore, I don't know a single argument that speaks against valid markup¹ so even if there weren't so many arguments speaking for it, validating markup wouldn't harm.

---

¹⁾ Well, there are “arguments”; however, most “arguments” brought forth are trivially proven wrong and none are supported by empirical data.

Answer 6

We do XHTML and CSS validation for all websites that we do. We find this important not only for maintenance reasons but to help us to be sure that we are not violating any accessibility standards that can be easily addressed. We would had to alienate some customers just because we weren't making our pages compliant. Nothing makes people more upset than if you ignore the obvious and cause them to have accessibility issues.

Of course, accessibility goes far beyond standards and validation but it is a critical concern in any validation discussion.

Answer 7

I validate my personal sites from time to time. To me the incentive is mostly the vanity of knowing that what I put together don't have any obvious, embarrasing mistakes.

I've got a couple of very simple bookmarklets that makes it easy to check the HTML/CSS of the current page, that I use:

javascript:void(document.location='http://validator.w3.org/check?uri='+document.location+';verbose=1;ss=1')

and

javascript:void(document.location='http://jigsaw.w3.org/css-validator/validator?uri='+document.location)

Answer 8

I do validate all CSS and HTML on my websites. I usually do this as a last step before release, just to make sure I haven't forgotten anything. Heck, some of my clients actually requested it in the past.

Sometimes I also uses validation as a "debugging" tool: Nesting error or forgotten closing tags on complex pages can causes the most horrible display bugs.

Answer 9

Would, but the validators return too many useless errors to make it worth my time.

Frankly, if a feature works in all browsers then it is going to get used, that boat has sailed. For instance back before CSS I would put row height in the TR, it works, it is easier than in each TD. Not in the standard? Well it is now, half the world is using it.

Now give me a validator that tells me about thing that are actually broken in browsers (not just paper specs) and you've got something worth using.

--- Hey: don't mod me down just because you don't like my answer. The guy asked if people validate their web sties, not if validating you web site is the best possible practice. A "No I don't" answer is just as valid as "Yes I do."

Answer 10

I validate as a matter of principle.

As far as the need to validate goes, I think it is unnecessary if you already know that your site will work for your demographic. However, without validation we're just regressing back to the IE ages when all we cared about was making our sites work in the popular browsers. There's something hypocritical about complaining about IE and its lack of standards when you don't choose to validate against them.

Answer 11

I do validate my sites and I think most people should. However, whether you choose to pay attention to what the validator says is another matter. During the early stages of building HTML and CSS, not validating your markup and CSS can cause lots of headaches. A valid page is more likely to work cross-browser and easier to debug when it doesn't.

But does the end result have to validate? Not necessarily, no. Theres plenty of legitimate reasons for not validating. Whats important is to be sure that you're doing it for one of those reasons, just saying "doesn't validate, who cares" isn't really good enough. Its better to say "yeah, I know that part of the page over there doesn't validate because of xx tag/attribute, I concluded doing it like that was the best way to achieve y effect".

So, my advice: run your pages through a validator often, understand what the results mean if it doesn't validate. If once you understand them you're still happy, leave it. If you don't understand them or you don't feel you can justify them, then you may need to rethink.

Answer 12

I generally validate template or high-traffic pages regularly, other pages from time to time. More than anything, I just use it as a sanity check.

The problem out in industry, though, is the supposing that just because a webpage validates, it is also accessible. This is gravely wrong. I would advise having a much stronger focus on human inspection of correct semantic markup.

Whether or not a deprecated tag or attribute or browser-specific css is being used is actually relatively trivial an issue. What's more important is that the site is accessible and that semantic markup is being used throughout. This, however, can only be assessed by human inspection.

Answer 13

I also try to validate everything because I find that my cross-browser issues are generally fewer if the page is valid. Usually there are only 1-2 fixes for Internet Explorer 7, if any, and maybe 5-6 for Internet Explorer 6. What I find most useful in writing valid code, though, is keeping the CSS and HTML simple. It doesn't mean that the layout can't be fancy, but if the code feels like it's a hack, usually there's a simpler way.

Answer 14

I always validate my code, doing this means I don't have to hack the css for "IE6" only fixes. I haven't used an IE hacked CSS in about a year and a half and wont ever again. In my experience so far, only poorly structured code (html, xhtml and css) needs to have the hacks in it.

Mauro

Answer 15

I think of it this way. There are only two kinds of HTML: valid and non-valid.

With valid code, we know what the browser is supposed to do with it.

With invalid code, we can't possibly know, because there's precisely one way to be valid, and an infinite number of ways to be invalid.

If a particular browser can't display your valid code correctly, you still have problems. But it's a much smaller set of problems.

Answer 16

Have you ever had an instance where not validating your site has hurt you or your company?

Where I work, our web application has been under development since the days of IE 5. Moving forward we never validated our site or updated existing pages to validate against current browser standards. As a result the site only works in IE, and only when Quirks Mode is enabled.

No other browsers can run the site. The site is also limited in the amount of new "Web 2.0" or "ajaxy" features that can be included because of the fact that many of them rely on Standards Mode, which can't be turned on because they would break existing parts of the site.

Generally I recommend always developing to standard technologies. It will ensure that things will work in the future. Sure, there may be bugs with existing browsers, but bugs are almost always guaranteed to be fixed eventually.

If there are bugs with existing browsers, try to find workarounds, or hacks for those specific bugs, but make sure they're "modular" so that you can remove them or limit them once they are fixed by the browser.

Answer 17

I have the XHTML Validation plugin for Firefox so that I can immediately see if there's an error on a page. If I'm going to complain about IE's standards compliance, I can at least avoid being hypocritical and actually following coding standards myself.

Over time this has had the added bonus of having fewer and fewer issues between browsers.

Answer 18

Another thing to consider, screen readers for people with disabilities.

There is a plug-in for Firefox that allows you to test your site and it is free.

Most other alternatives cost money.

This is called firevox: http://firevox.clcworld.net/

Answer 19

I put these links on my pages:

http://validator.w3.org/check?uri=referer

http://jigsaw.w3.org/css-validator/check/referer

And, I fix any errors they report.

However, I do not strictly rely on those checks. I also validate my pages against the major browsers.

I think standards are important. If your pages are compliant with the standards, they are more likely to work properly on the browsers you do not check against.

Answer 20

I always use validation, however I do not always follow it. There's a difference between following the rules and staying sane.

Imho validation is good because

• It helps all people that work with the code understand it, as validation is the common point of reference.
• It helps you become better at understanding concepts and you own code thus making you a better coder.
• It helps you from writing a billion nested divs, forgetting an end tag somewhere making the whole layout a mess(Once had to debug a billion lines of poorly written code with a billion lines of nested divs, which had not taken a billion years if the person who wrote that code had used validation.)

On the other hand

• Validation does not always mean that your code will display the way you want it, thus there's always a trade-of as with all standards.

A good validator is HTML validator plugin for FF which lets you do everyting in realtime instead of copying the code to some online validator. It's located here http://users.skynet.be/mgueury/mozilla/

Answer 21

I always validate the websites we create. I want the sites to validate as strict XHTML.

CSS on the other hand is a little bit different for me. I obviously fix the most obvious errors, but sometimes I include things that doesn't validate: things like filter-properties so stuff works in IE6.

I've started doing server side user agent checks and including an IE6 stylesheet lately, as this makes it easier to create a site that at least validates for the GOOD browsers ;)

If I were to look for a new job and saw an opening at a web development company, I'd take a look at their website, and I usually check the source and/or validate their site as sort of a quick measure on how "serious" they are about creating good clean code. I might be going a bit overboard, not many people would do this, but for me, it represents good clean code and the quality of the developers behind the code.

Answer 22

Interestingly, Opera just released a report that finds that most websites don't validate. Out of approximately 3.5 million sites surveyed, only 4.13% of the sites had valid markup. Their MAMA survey has quite a few more interesting findings that you should take a look at if you get a chance.

Answer 23

Yes, I validate HTML, I use -Wall when I'm writing C code, and I use the strict and warnings modules when I'm writing Perl. Why? Because I take pride in my work, and I want to do it well. IMHO, "good enough" isn't good enough.

Answer 24

I feel from a matter of archival integrity it is necessary to be standards compliant. Besides that- it is function of work cost and risk. Any developer who has the pride and the time will make sure things are complete. Developer without time and simply wants to get work done to get a pay check may never have even considered validation.

Answer 25

I find the running my code through a validator is useful for checking whether I've made any obvious mistakes. However, since I sometimes use non-standard elements (such as Apple's special search box: <input type="search" />), I don't aim to get a page 100% 'valid'—I just try to fix any problems that don't need to be there.

Steve

Answer 26

XHTML Strict. Always. There is no excuse to not validate. Lack of validation shows laziness. Nothing more nothing less. You don't have to advertise it to the world that your site is valid, but you should take the extra couple minutes DURING development to keep it valid. Once you start validating your code, you will gain the habit of keeping it valid. After a very short time, it will become second nature and your validation will become 1st nature.

Answer 27

I always go out of my way to make sure my HTML and CSS is valid. I always revalidate after changing anything. It seems to help reduce cross browser compatibility issues. However, I only validate as 4.01 transitional.

Answer 28

I once forgot a > in a site. It didn't have any impact in Firefox and it was much later that I noticed that the site totally broke in IE. A simple validation would have caught that error.

To make validating easier, I built http://vldtr.com/

Answer 29

I validate the code. But when developers take the html pages for coding, they remove html tags and add jsp, jsf tags. I am not sure if they real care to validate after adding those tags.

Answer 30

Yes, validating web sites you author is usually good practice. I've found the following Firefox extensions handy in doing so.

• HTML Validator Firefox extension (Windows only)
• Relaxed HTML Validator Firefox extension (Linux)

The W3C HTML validator is helpful as well.

One cool site is vldtr.com, which is a front end for the various W3C validators. You give it a URL and let it discover all the bits that it can validate, like CSS, HTML and RSS feeds. If you create an account you can save your list of sites and pages with a handy keyword. Check out the one for Stack Overflow.

Answer 31

I've recently finished a site where XHTML strict was a requirement. All the guys on the team were using Firefox add-ins, and more recently dev tools in IE, to validate against the W3C engine. Even then, too high a proportion of bugs that made it into test would have been caught earlier if we could have guaranteed everyone always validated (including different data conditions in the CMS). Now I'm looking at automating it. I've got HTML tidy running from a unit test runner, and I'm considering running a spider to do the job more thoroughly.

Why? Well apart from it being one of the project requirements, it also gave us lots of good feedback that prevented problems. The huge majority of rendering/CSS bugs were solved immediately once we fixed the html that hadn't validated. What's not to like?

Answer 32

you ever had an instance where not validating your site has hurt you or your company?

One of our clients was slated in the press for having non-conformant HTML. It was basically an article in a trade journal where some jumped-up "web consultant" was touting for work by publichsing an article comparing the web sites of leading companies [in that field] - well, that's my take on the matter!, but naturally our client wasn't happy that they were marked down for "poor quality HTML". Best as I can guess it (from looking at other sites in the article, and how they were "marked") all that had been done was to create a score based on the number of HTML Validtor errors.

I guess its fair to say that up until then we had been doing what another poster here mentioned: "Just make sure it renders correctly in all browsers". We did use HTML Validator, but only to look for goofy things that we had overlooked, not to be completely anal about it.

However, since this episode that policy has changed!