It is essential to validate one’s XHTML.
Anyone who does web development these days knows of XHTML. One of the benefits of XHTML is that it brings some of the strictness of XML to what, at least under previous versions of HTML, was often a free-for-all. It’s quite easy to check that your web page is valid XHTML. The W3C, for instance, offers a great web-based tool for validating your XHTML pages. But apparently not everyone thinks this is a good idea. Take this article that tries to give five reasons to never validate your XHTML.
In my opinion, the article is quite incorrect. And so I’d like to further analyze the article, pointing out its flaws and problems.
The first reason given for never validating pages is this: Visitors don’t care about validation. That’s quite an absurd statement to be making. Web site visitors are a very, very diverse crowd! No, a grandmother may not directly care whether or not your web page is valid XHTML. But if you run a technical site, you no doubt will have users who are aware of such things, and may check your pages. It gives me a very bad impression of a site and its authors when I find it is not valid HTML or XHTML.
Furthermore, it’s far easier for browsers to deal with valid XHTML code. Why is that? Well, it’s because the semantics of such code are very clearly defined. A good example of why this is necessary is obvious when we look back at previous HTML standards, and how many popular web browsers began to accept broken or invalid code. The browser developers would then have to guess what the author of the page actually meant with their broken HTML, and these assumptions would differ between browsers. But this isn’t the case when using validated HTML or XHTML code. The exact meaning is clear to the developers of the various web browsers out there, and thus the page will often render very similarly on all popular and capable browsers.
The second reason is perhaps the most pathetic of them all: Validation is time consuming. Wrong. Not only is it wrong, but it’s so easily disproven. For instance, you can validate my page here by clicking on this link. Yes, it’s that simple. If there are problems, you are alerted to exactly what those problems are, what lines are affected, and often what steps you can take the remedy the problem.
The third reason is this: Clueless clients. If a client wants valid XHTML, good for them. Give them what they want. If a client is not aware of what valid XHTML code is, give it to them anyways. It’s just what a responsible web developer should do.
The fourth reason misses the point: What are you trying to prove? The use of valid XHTML helps prove to web browsers that you know exactly how you want your page to display. And as I mentioned earlier, it shows your clients and the people who view your web page that you know what you’re doing. You’re not just hacking around. It shows that you’re a responsible web developer who knows of the community standards, and has enough talent, care, responsibility and understanding to write valid XHTML code.
A question is posted under the fourth reason: Have you ever visited a site that wasn’t validated so you decided never to come back again? Many times, in fact. A lot of those times, the page wouldn’t render correctly in the browser I was using, just because the page author lacked the ability or understanding necessary to make their page valid HTML or XHTML. A page is useless to me if the web developer was unable to properly specify to my web browser how that page should appear. And so I won’t bother to visit such pages.
The fifth reason again misses the point: Get some real work done instead. Writing valid XHTML is often a massive time saver. With the W3C’s great validation tool, it takes virtually no time at all to check that your page is valid XHTML. Furthermore, your valid XHTML page will likely render well in all of the major browsers, thus reducing the time you spend trying to track down and solve rendering problems.
Reading that article actually made me glad that I support the validation of XHTML pages. Each point the author of that article made was either incorrect, irrelevant, or completely oblivious to the challenges facing actual web developers. With the W3C making HTML and XHTML validation so quick, painless and easy, there’s really no reason for a page not to validate.
February 18th, 2008 at 6:27 am
I find it incredibly funny and quite ironic that this page doesnt actually validate. 1 error, which, of course you will probably fix then my post will have no meaning.
Anyway, that wasnt the real reason I wanted to post a comment. Some pages that we would like to be validated cannot because the developer has thought of helping the user. As an example of this I have created an XHTML .0 Trans page that doesnt validate. Fixing the page would unfortauntely make only the text on the links clickable (as seen on the left hand side of the page). However, it is much nicer for the user to be able to click the entire div (as it has been made to look like a button). You can see the page at the following address: http://www.myothersheepisacow.com/179-360innovate/
The W3C’s XHTML is of course a good guidline to follow, but it isnt always possible to make the page as user friendly and still have a valid page.
And to say that it helps browsers if your page is compliant is simply not the case. A perfect example of this is that so far only 1 broswer passes the acid 2 test (http://www.webstandards.org/files/acid2/test.html) - Opera, which very few of the web users actually run. Browsers are created to accept a compromise between accessibility, user-friendliness and valid html. The example in this page is enough to invalidate your entire post, as if everything went your way, this page wouldnt actually be readable by users visiting your website in a browser that only accepts valid markup.
Steven Freeman