I don’t care if a page I am viewing validates or not, but if I have to work with a page, I much prefer if it validates.
I’ve done bits and pieces of web design in my time, and 90% of the display errors I’ve experienced have been resolved simply by validating.
I was lucky, I only learned HTML 3 years ago, so I missed the 90s and the frames, and the like. But when I sat down to learn HTML I decided to learn it correctly. Why wouldn’t you. It is in my honest opinion as difficult to work with bad html as it is to write good html.
"Dans les cabarets de Berlin, un couple d’hacktivistes hermaphrodites milite pour un retour au HTML proltarien."
brilliant…
Xhtml is a good aim, but… when you are maintaining a trillion lines of HTML/ASP/C#/Javascript code (one day I will do the count…) it becomes a painful/expensive/useless aim.
If you need to transfer data between A B, you can either use a web service or generate pure XML on a regular dynamic page.
What a lot people keep forgetting is that XML was intended as a data container for it’s transport between systems. XHTML is another of those “one solution for all your needs”, brilliant if you get full-on support/implementation in your company but useless if you try to go halfway.
XHTML’s problem is the same as HTML’s problem: Shoehorning wildly different content into a small set of tags, and disallowing any extensibility (even if it’s fully-defined in CSS). Sometimes you need line breaks, sometimes you need footnotes, sometimes you need musical notes. Docbook and the other specialized sub-languages are better for the semantics crowd. Meanwhile W3C wants you to use their handful of random, semi-useful tags, and an enormous sea of divs and spans for everything else.
Only webheads can put up with that for long. Everyone else just wants it to look a certain way and usually doesn’t care about how it ends up doing so.
Though I don’t mind malformed HTML, but tag soup is unmaintainable. We should have middle ground somewhere between ‘clean code’ and ‘gold plated code’.
As some people have suggested, you should use the W3C validator like a lint tool or like compiler warnings. It can help you find typos - for instance I’ve just used it 5 minutes ago to find some mistyped id values in label for attributes in a colleague’s work that I’m updating.
If you understand the validator’s warnings you’re happy to ignore them, that might be fine. But I find it easier to check that there are no warnings than to skim through half-a-dozen to see whether any of them matter.
This is largely the result of bad tools, as Josh said. As the tools improve, the standards compliance will follow.
Tim’s article talked about backfitting XForms into HTML rather than keeping it in XHTML land. That may be a necessary tradeoff, but I’d think that one incentive to offer tool vendors and content producers is enhanced functionality: new features only valid in XHTML.
“Your browser doesn’t care if your HTML is well-formed. Your users don’t care if your HTML is well-formed. So why should you?”
Because it makes it easier to debug problems with your page. If you ask for help with a CSS bug on the css-discuss mailing list, the first thing people will ask is “have you validated your HTML”? This isn’t pedantry: if you have invalid HTML, you’re relying on the browsers (undocumented) error handling as part of the way it renders your code. If you have valid code and it’s rendering incorrectly then it’s down to a browser bug - and these tend to be pretty well documented by the community and hence much easier to work around.
All of that said, I prefer HTML 4.01 Strict as opposed to XHTML. It’s still a standard and you can still validate against it, but it comes without any “fail-on-error” baggage.
With few exceptions, I’m not convinced there’s much value in using or migrating to xhtml at this point. In fact, if you’re not serving your content up as application/xhtml+xml or text/xml, there’s no reason at all to bother with xhtml and plenty of reasons why it’s a bad idea (http://hixie.ch/advocacy/xhtml). The fact that IE doesn’t even support xhtml is not the least of these problems. This isn’t just about closing your tags and quoting attributes: core javascript methods like document.write and properties like innerHTML can’t be used either. This alone makes switching to xhtml impossible for 99% of ad-driven sites.
The programmer in me loves the the idea of cranking out perfectly valid xhtml and writing javascript that only uses the DOM Core methods. For the same reason, I try to write html that’s semantic and avoid div soup and use CSS for presentation. But most people authoring web content are not programers and the low barrier for entry is partly why the web is what it is today. The fact is, html needs to be highly fault tolerant. I agree with those who have advocated valid markup for readability/maintainability purposes, but let’s be honest: we’re the exception, not the norm. Table-based layouts are only just starting to become obsolete (if there’s a bigger readability killer than that, I’d like to see it). And look at google’s web authoring stats: http://code.google.com/webstats/2005-12/classes.html. The 13th most popular class name is “mso:normal”. When that many people are using MS Word to author documents for the web, it becomes abundantly clear how far we have to go to migrate to xhtml.
I think most people don’t care about using valid XHTML because it does nothing to guarantee browser compatibility. Just because my site validates doesn’t mean it will display the same across browsers. Until this is the case, I don’t see many developers caring about being valid. They just want their site to look right in the major browsers.
It is laborous to do things. It is even more laborous to do difficult things like standards. So, if some parties have achieved some standards that are adobted into world wide use, the parties have obviously done something really hard and laborous.
Well, nothing comes easy, except things that are not perfected for ever. So the results are of course what they are and that is less than perfect. We can forgive our heroic developers, because also time is money.
I think that when standards are made, some open source helping hands could be taking some of the development burden. Like Firefox is a good browser, so there could be some good open source standards.
And if the world is a mess, then if you provide some clean and neat service, you get the customers.
If something is allowed, then that is a feature. If you didn’t mean to allow it to happen but allowed anyway, its too late - you have a feature. Lets consider a game like World of Warcraft. There is a glitch that allows snoopy players to go behind the scenes. Is this ok? Well, it does not matter. Some players go behind the scenes anyway. You could fix this so that the users are not allowed to go behind the scenes, but would that be ok? It does not matter. The users just could not abuse the glitch anymore.
Would it be easier for the users to be in the right side or go through glitches? It depends, but it would really be helpful to know what is the right side. And it would really be helpful if the scenes were intact without lots of holes and traps where to fall through if you didn’t want to.
