If I've tested my pages in most major browsers, why would I need to maintain a validated code? I want to use box-shadows and corner radius if they're supported in WebKit browsers and Firefox. I don't care if they don't show up on Internet Explorer. But I keep my HTTP requests down by not including images instead.
Are there are advantages to valid code? In SEO or otherwise?
The standard is only a suggestion, as you can write your own DTD and decide shadows are part of that standard and then your page would validate just fine.
The existing standards are work in process which are being affected by many parameters, not all 100% professional/technical.
The main reason to use standards is it is said will cause your page to render the most similarly between browsers (at least those browsers who support standards :-) )
As long as it works in the browsers you care about then it doesn't matter. In theory your maintenance costs might be lower with validated code.
You have to determine what the success criteria for your project is. If your program does what your client needs then just because you code is "valid" doesn't make it more magical in and of itself.
Invalid css/html may become horrible to maintain. Changes may have unwanted effects, which are hard to fix.
"Valid" code isn't so much important as "semantic" code. If there are font tags all over the place and list tags that don't close, it'll be both difficult to maintain and hard to parse with strict and proper xml parsing engines.
This is no different than asking if there are advantages to writing syntactically valid C code: Such a program need not do the right thing but doing the right thing without valid code will be harder.
Related discussion on SO: Do you validate your websites?
Validating code is one can prevent many find and hopefully fix many problems in your html/css that could cause undesired results. IMHO its more of a "common things that could be wrong" fix than a replacement for testing. If you like the look you're getting in the browsers you want, I wouldn't worry too much about the validation.
(Yeah, you can put the little badge on your website if you want everybody to know you use validation to check your site) :D
Because, only by knowing the rule, will you know when to break it.
Using browser-specific extensions isn't bad, but it is something you want to do on purpose, not blindly.
Validation points out the places where you deviate from the standard. Maybe you needed to, maybe you didn't, that decision is yours.
I'd say valid (X)HTML is a must, since this defines how your content can be accessed. Badly formed HTML can stop your content from being "read" by not only humans but also machines (think search-engines, spiders etc). Imagine if a bank held your account details in a badly formed XML file and then sent that XML to another bank as part of a transaction - there is a danger that the bank would mis-read the amounts due to the different way it tried to interpret the sums.
Valid CSS is slightly different as it is purely stylistic and effects presentation, not content. Therefore it is not as essential to keep it valid, so long as you don't mind different user agents presenting your content in different ways.
One reason for having valid HTML is for accessibility. Screen reading software for visually impaired users works much better if the HTML on the page is valid.
There are sometimes css or html attributes that are marked 'invalid' by some validators, but you shouldn't worry about this. Using box-shadows and rounded corners is no problem at all. Browsers that do not recognize them will simply ignore them, so no trouble there. I'd even encourage you to use those - if too many people would wait using those until they're widely supported, the web's momentum would become much too large.
However, there is a reason for having a valid HTML structure in your document. It isn't hard at all, and it'll save you encounters with inconsistencies in wrongfully-shaped-document-handling across browsers.
I never really understood why we are actually allowed to write structurally invalid HTML. Document readers will most likely barf out PDFs that aren't well-formed, but HTML 5 even seems to have a formal specification for error handling...
Ask that to all the people who wrote code that worked fine when they tested it in IE 6 and then it broke when IE started supporting the standards better.
You can't test in browsers that haven't been released yet!
Browsers tend to become more standards compliant over time. If you write standards-compliant webpages, they're more likely to still work in the next version of all existing browsers.
I'll answer by an analogy. What you are saying is like saying I like building my cars with square tires, it might not be valid everywhere, but it works for me.
If you do not make a product that can be available by a maximum of people, how do you expect your product to be known and used by a maximum of people. By ignoring people that are using IE (which is still the majority of people, by the way) your shooting yourself in the foot. You need to create something that can be used by a vast majority of people while trying to follow the standards for those browsers that do follow them.
Here is another point... If you're writing a SharePoint web part, you can just about the worst possible, messy, cruffy and dodgy HTML you could possibly imagine, and your web part would feel right at home in SharePoint.
It actually amuses me seeing purists try code valid HTML strict for a MOSS plugin when the entire framework spits out garbage.
Its no wonder you can't find anything on a corporate intranet....
You should always have valid (X)HTML because there are very few occasions where the benefits of not having valid code outweighs the benefits of not having validated code.
For CSS, however, there is little reason to be as strict. All your CSS should be proper and work as intended, follow best practices and optimize where possible. Other than that, use all the browser specific experimental stuff you want, it won't noticably affect other browsers.
The best reason to follow a standard is to reduce fragmentation of the standard, which leads to instability.
If everyone breaks the standard in exactly the same way and it's well thought-out, then that's not as much of a problem. Over time the standard will evolve to match what has become the common practice. Look at how modern HTML has moved on from SGML comment rules, tag minimisation, etc, and how <!DOCTYPE html> is enough to trigger standards mode. These are all against the standards but are common practice, and now the new standards (HTML5) are even evolving to support these.
If everyone breaks the standard in a different way, through general sloppiness or through wanting to invent their own 'hack', then the standard does not evolve, but it fragments. Browsers have a harder time supporting every different direction that people have gone in to hack something so that it looks right (or just through sloppy mistakes). They've done a good job so far of remaining backwards-compatible, but it's been at the cost of a huge increase in parser complexity. Sooner or later, however, less popular or more obscure hacks or errors stop being supported, because they were just stupid ideas to begin with (various CSS selector hacks come to mind) or they were just too far out of left-field (the <layer> element, and so on).