March 5, 2009
But it doesn't have to be this way. There are provisions and mechanisms for validating your HTML markup through the official W3C Validator. Playing with the validator underscores how deep that forgiveness by default policy has permeated the greater web. Dennis Forbes recently ran a number of websites through the validator, including this one, with predictably bad results:
FAIL - http://www.reddit.com - 36 errors as XHTML 1.0 Transitional. EDIT: Rechecked Reddit, and now it's a PASS
FAIL - http://www.slashdot.org - 167 errors as HTML 4.01 Strict
FAIL - http://www.digg.com - 32 errors as XHTML 1.0 Transitional
FAIL - http://www.cnn.com - 40 errors as HTML 4.01 Transitional (inferred as no doctype was specified)
FAIL - http://www.microsoft.com - 193 errors as XHTML 1.0 Transitional
FAIL - http://www.google.com - 58 errors as HTML 4.01 Transitional
FAIL - http://www.flickr.com - 34 errors as HTML 4.01 Transitional
FAIL - http://ca.yahoo.com - 276 errors as HTML 4.01 Strict
FAIL - http://www.sourceforge.net - 65 errors as XHTML 1.0 Transitional
FAIL - http://www.joelonsoftware.com - 33 errors as XHTML 1.0 Strict
FAIL - http://www.stackoverflow.com - 58 errors as HTML 4.01 Strict
FAIL - http://www.dzone.com - 165 errors as XHTML 1.0 Transitional
FAIL - http://www.codinghorror.com/blog/ - 51 errors as HTML 4.01 Transitional
PASS - http://www.w3c.org - no errors as XHTML 1.0 Strict
PASS - http://www.linux.com - no errors as XHTML 1.0 Strict
PASS - http://www.wordpress.com - no errors as XHTML 1.0 Transitional
In short, we live in malformed world. So much so that you begin to question whether validation matters at all. If you see this logo on a site, what does it mean to you? How will it affect your experience on that website? As a developer? As a user?
We just went through the exercise of validating Stack Overflow's HTML. I almost immediately ruled out the idea of validating as XHTML, because I vehemently agree with James Bennett:
The short and sweet reason is simply this: XHTML offers no compelling advantage -- to me -- over HTML, but even if it did it would also offer increased complexity and uncertainty that make it unappealing to me.
The whole HTML validation exercise is questionable, but validating as XHTML is flat-out masochism. Only recommended for those that enjoy pain. Or programmers. I can't always tell the difference.
Anyway, we validated as the much saner HTML 4.01 strict, and even then I'm not sure it was worth the time we spent. So many of these validation rules feel arbitrary and meaningless. And, what's worse, some of them are actively harmful. For example, this is not allowed in HTML strict:
<a href="http://www.example.com/" target="_blank">foo</a>
target, a perfectly harmless attribute for links that you want to open in a different browser tab/window, is somehow verboten in HTML 4.01 strict. There's an officially supported workaround, but it's only implemented by Opera, so in effect .. there is no workaround.
In order to comply with the HTML 4.01 strict validator, you need to remove that
Does it really matter if we render stuff this way..
.. versus this way?
I mean, who makes up these rules? And for what reason?
I couldn't help feeling that validating as HTML 4.01 strict, at least in our case, was a giant exercise in to-may-to versus to-mah-to, punctuated by aggravating changes that we were forced to make for no practical benefit. (Also, if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window.)
That said, validation does have its charms. There were a few things that the validation process exposed in our HTML markup that were clearly wrong -- an orphaned tag here, and a few inconsistencies in the way we applied tags there. Mark Pilgrim makes the case for validation:
I am not claiming that your page, once validated, will automatically render flawlessly in every browser; it may not. I am also not claiming that there aren't talented designers who can create old-style "Tag Soup" pages that do work flawlessly in every browser; there certainly are. But the validator is an automated tool that can highlight small but important errors that are difficult to track down by hand. If you create valid markup most of the time, you can take advantage of this automation to catch your occasional mistakes. But if your markup is nowhere near valid, you'll be flying blind when something goes wrong. The validator will spit out dozens or even hundreds of errors on your page, and finding the one that is actually causing your problem will be like finding a needle in a haystack.
There is some truth to this. Learning the rules of the validator, even if you don't agree with them, teaches you what the official definition of "valid" is. It grounds your markup in reality. It's sort of like passing your source code through an ultra-strict lint validation program, or setting your compiler to the strictest possible warning level. Knowing the rules and boundaries helps you define what you're doing, and gives you legitimate ammunition for agreeing or disagreeing. You can make an informed choice, instead of a random "I just do this and it works" one.
After jumping through the HTML validation hoops ourselves, here's my advice:
- Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
- Nobody cares if your HTML is valid. Except you. If you want to. Don't think for a second that producing perfectly valid HTML is more important than running your website, delivering features that delight your users, or getting the job done.
But the question remains: does HTML Validation really matter? Yes. No. Maybe. It depends. I'll tell you the same thing my father told me: take my advice and do as you please.
Posted by Jeff Atwood
@Paolo: I decided to go back and validate a couple of my latest projects. It took me about 30 minutes a pop and it was a bunch of meaningless edits that had absolutely no bearing on whether my HTML was well formed or not.
What does well formed mean to you?
To me that sentence makes no real sense at all. Doesn't well formed imply that it follows a standard? If your HTML was invalid then surely by definition it was not well formed?
oh god, I really hate the target=blank, it just makes my experience worse, i do know were i want the webpage to be open, i don't need any web designer to tell me that i need a new windows if he thinks i need it.
other important point, there is a huge advantage to follow standards, how do you like have to make workarounds to have the layout look close, no the same just close, on IE and FF? well, i hate it, at least the standards give me a little faith that it will be the same, without workarounds.
and I do care if a website that I make is validated, it is simple, there IS people that NEED to use screen readers, they don't have option, if I have the option to make their experience better, i will try to, regardless if there is a lot of them to increse my view counter or not
For a blog with a focus on best practices, this seems like a very perverse post.
@Jeff: When it comes to #4, I'd argue you really want an *API*, not a brain damaged wow, we can scrape your site as XML! mentality.
Although I know of some actual programs that live scraping other sites pages, I was referring to what you say, an internal API to build XHTML, to build a piece of markup that may be placed inside a web page, or sent to a less forgiving parser :-)
@ Screen Reader Advocates
Does having a website validate mean that it is screen reader friendly? I'm sure it doesn't hurt, but placement of navigation links, descriptions in hyperlinks, alt and desc (used anymore?) tags on images seem to be more important than validation.
I wonder how many people actually have used their sites with a screen reader, but they can be downloaded for free (very nice plugins for FireFox).
Point is that screen reader browsers behave a lot like others like FireFox/Chrome/IE where they do their best to make sense of gibberish and in most cases do a great job at it, even if the page doesn't validate.
The number one reason to use XHTML over html is that it contains an X - in some way it sounds way cooler!!! That's a naming that has a lot of following nowadays. Lot's of shit contains XXX. I should say that web development has got all XXXX (X-racy) - he he!!!
(Also, if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window.)
If it is user-generated code, it should be inside a code tag...If you're talking about posts, limit the HTML they can use and check to see if it is valid.
You don't need to use XHTML, just make sure you validate strict. It is easy to do, and important if you want to have a properly formatted page with CSS. There is no CSS for invalid HTML, there are only hacks.
As a front-end designer/developer, I'm one of the few who does actually care if a site validates or not. Sure, I don't spend all day pinging URLs at the W3C validator, but if I DO happen to discover that a site doesn't validate, it lessens my respect for the site. It's a sure sign that the person behind that site is either too lazy, too ignorant, or just doesn't care about what they're producing. Conversely, if *that logo* is present, and leads to a successful validation result, I'm immediately given confidence in that site.
I can't believe you actually thing 'target=_blank' is reasonable behaviour in the 21st century. The rest of us have moved on.
why write prprly f u get yr msg undrstd nywy?
I think that's precisely why.
I must say, I'm incredibly disappointed with this post. If everyone just did as they pleased, the Web would be a very messy place. Oh wait...
Keeping standards is Web development 101. I can't believe I'm reading differently on this site.
It's one of the reasons I love Python so much. People are forced to keep their code readable, in terms of indentation standards.
i'm not trying to be mean, but having been writing html and xhtml as strictly as possible since about 1998 (html 3.2 eeewwwww), i gotta say - all i'm hearing out of this post is alot of misunderstanding and laziness.
i think marge is taking things the wrong way
i'll expand on what i mean - just a little bit. i have little interest in writing a full article here.
this may sounds counter-intuitive, but it is actually EASIER to write for strict DTD's and it's it EASIER to write for strict XHTML over HTML. there are fewer rules, less loopholes, etc - however you wish to put it.
markup isn't hard per se. it's more of an exercise in discipline and rigor than anything else. that's why i use the term 'lazy'. i'm not trying to insult anyone. there are things i'm lazy with - but i'm not lazy with my profession.
Some people on here are out of control.
1. To those who say using target=... is annoying... sorry! This blog is obviously filled with readers who know how to use their browser. I write web apps for a health care company and see employees who get hired and have to be shown what a mouse is. Try explaining how to open links in new tabs when desired vs. opening them in the same window. If they click an external link, they think they're booted from your app! So, as a programmer, I try not to think of the 3% of the company that can use their browser properly. I think of the 97% who can't.
2. Code validation DOES help your scripts run better. Think about one o the cardinal rules... have you ever had two elements with the same ID on a page and tried to document.getElementById() in your js? To make things FULLY cross browser compatible, it is less likely you will be able to validate your CSS, but your HTML should be ok. It's a good guide to keeping clean, but don't let it break your heart f you have to deviate to get something to work right. The question should be, if you need to hack together some malformed html / css to get your page right, how can you limit that code down to the browser you're trying to fix while getting the other browsers to ignore it?
3. If you see a set of rules as just a way to make your life harder, then get out of programming! It's all rules... and generally strict ones at that. People who throw out standards completely are just shooting themselves in the foot. I've tried to debug pages with display issues, and it is by far easier to debug when the original author at least MILDLY tried to follow the standards. It does make a difference.
From Nick on March 6, 2009 08:16 AM
HTML is not a visual formatting language, it is a language for defining
document structure. [...] The correct way to define the appearance of your
site is with css styles. Doing this separates presentation from content, and
makes your content more re-usable.
The vast majority of HTML pages are not about document structure. They are in
fact about presentation. The web designer is making content to present to the
user to read.
Style, size and font attributes let's one express visual changes succinctly and directly. Using css styles, especially with external css files is unnecessarily complicated for many common cases.
Why make things difficult?
Now, *if* you need configurable and consistent style control across a set of pages, then great, use css styles when ultimately save more trouble than they cause.
But don't force their use.
Consider (if there actually was html allowed in these comments) bthis/b bolded word. How would it help anyone if I was force to have a css style to express that the word needed to be bolded? Using the b.../b conveys it directly and is easy to type. Sure, a machine could do it, but why force the use of more complex software when it is not actually necessary?
For supporting true structured data requests, HTML is pointless anyway. Just use web requests that return data in directly machine usable form.
Since the validator doesn't run the JS, it'll never know you use target's on your website.
Working demo on my blog :)
I run a couple of non-profit sites that validate to XHTML 1.0 transitional. It's not terribly difficult to do so, but the sites are also very simple in their design.
I think the main advantage to using valid XHTML transitional is that it is always well-formed markup; browsers parse these pages more quickly and they appear to load faster. They render more predictably across different browsers and they also render very well in wireless devices with no additional modification.
If you use a good HTML editor a validator and are familiar with web standards, it's just as easy to write valid markup as not, with the advantages mentioned above. Your mileage may vary.
Snorey, is your website static or not? Makes a big difference of course... Generated HTML from a dynamic (CMS, Blog and so on) isn't always in your control (not self made) and can generate invalid code..
@Tom: If your point was that grammar makes it easier to understand your point, you've made that point very clearly. But by doing that, you've proven that good grammar is unnecessary to make your point very clearly. But then you haven't made your point very well..
The point I was making is that while it's true you can get the point across using poor grammar (read: standards), it's merely passing the buck - you're making the reader (user) do the work for you. Misunderstandings are far more likely.
You realise that by giving a document a presentation you're implying structure? Structure and presentation are not mutually exclusive. So yes, a vast majority of HTML pages ARE about structure.
Style, size and font attributes let's one express visual changes
succinctly and directly. Using css styles, especially with external
css files is unnecessarily complicated for many common cases.
Isn't that what the inline style attribute is for? Rather than having a tag for EVERY type of formatting, you have css properties. Otherwise why just have b, i etc. and not the whole arsenal?
How would it help anyone if I was force to have a css style to
express that the word needed to be bolded? Using the b.../b
conveys it directly and is easy to type.
Isn't that what strong and em are for? They describe structure, and imply presentation. b just describes presentation without saying why it needs to be that way.
CSS is meant to make things simplier anyway. If you want to change the appearance of something, you don't have to go searching through all the content to change it. If you also want to apply all that change, you can instantly. And if you want to edit some content, you don't have to wade through a mass of presentation junk.
This is the typical post that Jeff posts when audience goes a little down. Nothing gets more traffic than a debate. Ofcourse he is wrong. He knows he is, we know he is. But being wrong in the right way can be fruitful.
I would love to fix www.microsoft.com's XHTML errors, but I've got bigger fish to fry.
part of the benefit of using html to describe the TYPE of content and not the appearance of the content is searchability, or in more broad terms - machine readability. xhtml rules help with this also - it's simply easier to parse something with can be counted on to have a sane structure at the most basic level.
also, who here wouldn't want a smaller, faster browser? all this cruddy, invalid html support comes at a cost. any team who makes browsers has to add in the ability to drag in garbage and spit out gold. the cost in development time, testing time, speed, and space are not insignificant.
also, i think it's shameful for people who work professionally in a craft to care so little for what they are doing. (so that's not aimed at people who don't do this for a living, please calm yourseves ;))
also, who here wouldn't want a smaller, faster browser?
I know I would. But I don't expect to see it when the browser has to implement a thousand pages of bullshit standard.
The problem is the system isn't designed properly. It's a giant mess. It is overcomplicated with the folly of wanting to support web applications.
A new web should be designed with a lean, meaningful standard, covering useful stuff and ignoring useless stuff. It should have a comprehensive test suite and reference implementation from day one.
But this will never happen. Everyone will keep throwing more and more at the existing garbage, bloating up the worthless standard, bloating up the unstable browsers, bloating up developer's minds.
All we can do is wait for the inevitable day when it comes crashing down under its own weight.
@Joe (three up): It's highly ironic that microsoft uses an xhtml doctype..
When it comes to validation: Know the rules, live by the rules (for a while at least) and learn when you can bend/break them. *Don't* break them out of misplaced laziness. Triggering standards mode makes me happy (use FFox+WebDeveloper and a green V will make you happy too).
This is just more communal jibber jabber. There *are* big problems with all this tag soup out there.
From Jon on March 10, 2009 03:09 AM
You realise that by giving a document a presentation you're implying
structure? Structure and presentation are not mutually exclusive.
Of course. My point is to argue against the notion that web designers must give an HTML document a display-agnostic structure in the usual case. In practice people don't do that. They in fact don't need to. Note that this is an orthogonal issue to the writing of clean maintainable code/html/markup.
It all depends what your goals are. Style sheets are a useful tool, but they need not be mandated for all cases.
Isn't that what the inline style attribute is for? Rather than having a
tag for EVERY type of formatting, you have css properties. Otherwise why
just have b, i etc. and not the whole arsenal?
It is not the precise syntax I was caring about. Inline style attributes are fine too. What I really object to is the forced separation of display and content, since the work required to associate them can cause unneeded complexity for the simple case.
If I just need to bold something, why would I use anything else except b? It's meaning is clear, and succinct. If I am not intending for the page to used in any other content other than this particular HTML usage, then why pay the cost of maintaining a display-agnostic content?
Do the work you have to and no more, and that work you do, do it right.
CSS is meant to make things simplier anyway.
I in fact use CSS when it helps me, notably when I have shared styles that give sets of pages a consistent look and feel.
From janos erdelyi on March 10, 2009 07:48 AM
part of the benefit of using html to describe the TYPE of content and not
the appearance of the content is searchability, or in more broad terms -
This seems reasonable on the face of it. But when you dig into each problem, there are simpler ways to do it. Instead of forcing the web designer to take the care to have display-agnostic displayable pages (!), searching is solved by stripping out all markup.
As for machine readability in general, having any sort of processing based on scraping web pages to derive query or report results is asking for trouble. It is far easier to have the web site support a reasonable web service API where the artifical HTML parsing problem can be completely avoided, and results given directly in a form where they can be readily consumed.
also, who here wouldn't want a smaller, faster browser?
For what it's worth, I too would prefer a web standard that was not so lenient, with clean parsing rules.
You really should stop advocating sloppy quality. We all get that you're a kickass programmer, but as of late, you've been making people have doubts. First you say that the SOLID principles are bureaucratic and moot, and now you say that validating HTML is not that important.
Most novice developers will read your blog and fail to take your advice with a grain of salt. You have a large influence in the software development community and lately, you've been very callous. The more experienced devs will instantly recognize when you start spewing non sequiturs such as this blog post and actually give you the reasons on why you're wrong. Unfortunately not everyone will instantly recognize this or take the time to read the comments especially if they are being read in an a blog reader such as GReader which does not show comments.
Please be more careful on what you write in your blogs.
Validation will be more important when google decide to make it a variable in the pagerank algorithm
Not writing valid XHTML because you can get away with it is like saying you don't have to write good code if the compiler lets you get away with it. People need to realize that HTML is not just for making text look pretty. HTML IS code, and should be respected accordingly.
As what stated before, you should want to use XHTML and serve with an XML content type so you can use SVG. SVG is being supported a lot more on the mobile space and even though Adobe has dropped it it is still a very important technology.
Yes, IE doesn't understand it, which is why you need to do some content negotiation on the server. And, in some cases, it might be possible to serve up some VML for IE. Also, you can always generate PNGs from your SVG if you need to.
Yes, it takes more work to do this, but just because doing something is hard doesn't mean you shouldn't do it. The user experience comes first, always. If you don't respect your users they won't respect you.
Jeff: There's no need to make a horrible aliasy version of the valid HTML 4.01 icon by scaling up the thumbnail: W3C have an a href=http://validator.w3.org/images/valid_icons/valid-html401-v.svgSVG version of that icon/a and you can either use it directly, or scale it to a size of your choosing and then rasterize the result.
Hear hear! I can still remember being chastised in front of the class by one of my tutors at University for not validating HTML - I should have asked him how many validation errors he thought Amazon had. (hint: lots more than mine).
Eh, I can sympathize with both sides. Yes, standards are important, and yes, as a programmer I vastly prefer strict error handling than sloppy ah, we'll make sense of your code somehow, don't worry. In theory, XHTML is nice enough. In practice, it's almost useless because of lack of support, inconsistent backwards compatibility (allow the same MIME type as HTML for backwards compatibility and make a few other concessions and then pretend it's compatible, and ignore the half dozen differences that would make a proper HTML parser choke on even the simplest XHTML document.
And then we have the even older HTML4.01 which was just a huge mess from the beginning and just.... sucks. It's a pain to parse, not a single browser does it correctly (it's ironic that the article Jeff linked to actually uses browsers shortcomings at parsing HTML as a reason not to use XHTML) and other agents have a hell of a time extracting data from it too (Certainly doesn't make it easier for the semantic web or microformats to take off if parsing a web page is all but impossible)
So we have a choice between the spec that works in theory, but not in practice, and the one that's completely flawed in theory, but which actually works ok'ish in practice because everyone are willing to bend the rules a bit, and browser vendors go to the most insane lengths to make sense of malformed HTML.
Thank you, W3C, for making web development such a hell. It's like every other bad decision in the history of computers rolled into one. All the messiness of the Windows API, x86 CPU's and C++ rolled into one.
I agree, nobody gives a rat's ass about validation in the real world. Only overstuffed pompous web developers who probably sucked up to their mother's all their lives and still do at the age of 35. Just give it 5 to 10 years (if the web is still around), either validation will kick in and a web page won't display at all until it's valid -or- validation standards will become such a problem, they'll just fall off the end of the earth and be one of those I remember the day when... things. For the time being, who cares if if validates!
Actually the doctype trick works well in Konqueror as well (as of 4.2.61 at least).
To answer your question I mean, who makes up these rules? And for what reason?, this is why:
HTML: HyperText Markup Language
What wikipedia says about markup language: A markup language is a set of annotations to text that describe how it is to be structured, laid out, or formatted.
Markup language describes the *STRUCTURE*, not whether that structure should float: right or have a red background. This is what makes width=80 bad and style=width:80px good.
At first everyone complained about the apparent lack of standards on the web, and now that we have them everyone started complaining it's too strict.
Yes, damn it all, let's make it even more strict! I don't see anyone complaining about C++ compilers not allowing sloppy code mixed with..oh I don't know..PHP? ..yet everyone picks on HTML. WTH?
As a web developer, I can't understand why people make such a big deal about coding in html or xhtml, I prefer xhtml because it appears much cleaner in my eyes and validating isn't hard, we do it on every project and very rarely have to bend the rules for complete cross browswer compliance. Whats the big deal? if you find it that hard, what else do you struggle with?
next thing you're going to proclaim 'vote tables for layout'...
Badly need your help. Awesome website, glad we found you. Help me! There is an urgent need for sites: kitchen islands. I found only this - a href=http://purifiersair.biz/Air purifiers uk/a. Select flights to track from airline websites with the yapta browser add on. To book your flight visit palas travel cheap airline tickets travel deals. Best regards :mad:, Lobo from Kyrgyzstan.
In my opinion with a valid code by W3C you will be sure that your content will be indexed by crawlers.
Excuse me. If we fall, we don't need self-recrimination or blame or anger - we need a reawakening of our intention and a willingness to recommit, to be whole-hearted once again.
I am from Ireland and too bad know English, give true I wrote the following sentence: Low on thyroid, use synthroid to your benefit.
Best regards :-D, Lloyd.
Sorry. What more felicity can fall to creature, than to enjoy delight with liberty.
I am from Cape and learning to write in English, give please true I wrote the following sentence: Purchase synthroid without a perscription.
Thanks for the help :o, Melba.
The very good post
the congratulations of this blog .. I will return several times
to check the content!
xhtml strict and all this fucking bullshit validation garbage is for those cum lickers who think validation is so important to our lives.
validation is a load of old cum shit.
those that think its so important need to fuck off and stop fucking their mothers.
people are dying in third world countries, and you think by making a shitty piece of html or css valid is going to improve your life?
life is too short to fucking waste on "validation".
validate my big black cock if you are so enthusiastic about it people.
This goes to Nick, whos site is http://www.charcoaldesign.co.uk/
You talk a big game here, yet your site is invalid.
Do not speak when you can not backup what you act like you do yourself.
A lot of people make their own website. They are not pro designers and they have no clue about validation, and they are not departing. Their number is increasing and they will sometimes use tools that produce fairly valid code, but often not.
Most comments here are entirely focused on pro web development, but that's not 100 percent of the web and it never will be. Sorry, but you will never have an exclusive web club that eschews imperfection.
www.codinghorror.com/blog/ got :42 Errors, 57 warning(s)
Google Seo,search engine optimization,seo techniques,google adsense
The concepts mentioned above are not olmassa for a site ..
Thank you for this article .. Anyone can inform ..
Google Seo,search engine optimization,seo techniques,google adsense
The concepts mentioned above are not olmassa for a site ..
Thank you for this article .. Anyone can inform ..
Typically when I see that button, my first thought is lets see how much of a lie this is. And about 70% of the time I'm right. :-)
@Rick Dailey: Your comment makes too much sense - Jeff doesn't care because being reasonable and non-combative doesn't attract the quantity of traffic that Jeff has become accustomed to. Passionate opinions, even if uneducated, misguided or just plain wrong, polarize people and get them riled up. That's good for business.
In actuality, I guess the best result from posts like these is the resulting conversation, and that is what blogs should do - start or participate in a conversation with the readers. I just don't know that this particular conversation is useful...
Oh boy Jeff... Please don't spread this kind of amateur misinformation.
That's right, target, a perfectly harmless attribute for links that you want to open in a different browser tab/window, is somehow verboten in HTML 4.01 strict
Does it really matter if we render stuff this way... ...versus this way?
Jeff, the two examples you gave are both bad. We're talking separation of concerns here. The second one with the style attribute properties should have been pulled out to a CSS document. How can you not know this, given that you've already made the somewhat flawed analogy between html and css as the model-view-controller architecture? Presentation data goes in a stylesheet, while the information goes in the HTML document.
A simple compromise:
Use the validator to highlight *potential* errors, then correct the ones you agree with.
As a mobile web developer i hated validation but it was a must for WML.
I know so obsessed with it that i validate most of the web sites i visit :S
I don't agree with this: 'The whole HTML validation exercise is questionable, but validating as XHTML is flat-out masochism.'
Different coders have different styles -- and many of the best websites don't validate -- but writing valid XHTML just isn't that hard!
Whatever -- I think the main reason to write completely valid (X)HTML is to avoid *malformed* code (e.g. missing end tags) rather than *invalid* code (e.g. an input as the direct child of a form element).
Whenever you see a validity error (e.g. with a Firefox add-on, or in a build process or whatever) you know there might be a problem with HTML structure. Malformed code can cause problems that are hard to debug. This is particularly true for pages that are built dynamically.