Even though I always strive for complete validation these days, I often wonder if it's a waste of time. If the code runs and it looks the same in all browsers (I use browsershots.org to verify) then do I need to take it any further or am I just being overly anal?
What level do you hold your code to when you create it for:
a) yourself b) your clients
P.S. Jeff and company, why doesn't stack overflow validate? :)
EDIT: Some good insights, I think that since I've been so valid-obsessed for so long I program knowing what will cause problems and what won't so I'm in a better position than people who create a site first and then "go back and fix the validation problems"
I think I may post another question on stack overflow; "Do you validate as you go or do you finish and then go back and validate?" as that seems to be where this question is going
W3C validation helps you to get better rankings in search engines (SEO). Errors in your code can affect your site's performance and make a big impact on your site's SEO. Search engines check the HTML or XHTML code of your website when searching.
Clean, compliant HTML and CSS code help in this process. Compliant code makes it easier for search engine crawlers to identify what the content on a webpage is, and what that content means.
Valid HTML code will help assure that your site renders well across all browsers, including the version GoogleBot uses for rendering websites. For example, CSS Custom Properties is not supported by version of Chrome used by GoogleBot for page rendering (Read: Google Engineer Issues Warning About Google Crawler).
Validation can be used as a debugging tool – Validators tell you where you have errors in your code. If your page isn't displaying as expected a validator might very well point you to the cause.
a) Must look the same
b) As standards-compliant as possible, but not so anal that it blocks finishing work
In a situation where you have perpetual access to the code, I don't think standards-compliance is all that important, since you can always make changes to the code if something breaks. If you don't have perpetual access (ie, you sign off on the code and it becomes someone else's responsibility), it's probably best to be as standards-compliant as possible to minimize maintenance headaches later... even if you never have to deal with the code again, your reputation persists and can be transmitted to other potential clients, and many teams like to blame the previous developer(s) for problems that come up.
I think this is an area in which you should strive to use the Robustness principle as far as is practical (which is good advice for any area of coding). Just because something works today doesn't mean it will work tomorrow: if you're relying on a particular HTML/CSS hack or even if you've just been a little lax in emitting strictly valid code, the next iteration of browsers could well break. Doing it once the right way minimises this problem (though does not entirely mitigate it).
There is a certain element of pragmatism to take here, though. I'd certainly do all I could for a client's site to be valid, but I would be willing to take more risks in my own space.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With