Markup Validation Service
Check the markup (HTML, XHTML, …) of Web documents
Markup Validation Service
Check the markup (HTML, XHTML, …) of Web documents
This document attempts to answer the questions many people have regarding why they should bother with Validating their web sites and tries to dispel a few common myths.
The original version was written by Nick Kew of WebÞing Ltd. for their Site Valet service and he has generously donated it for our use.
The document has been updated over time, notably thanks to the many Web authors who shared their own rationale and motivation for using Web Quality checking tools.
In early 2009 we asked the Web community if they thought there still was a strong motivation for validation. Here are some reasons they mentioned:
While contemporary Web browsers do an increasingly good job of parsing even the worst HTML “tag soup”, some errors are not always caught gracefully. Very often, different software on different platforms will not handle errors in a similar fashion, making it extremely difficult to apply style or layout consistently.
Using standard, interoperable markup and stylesheets, on the other hand, offers a much greater chance of having one's page handled consistently across platforms and user-agents. Indeed, most developers creating rich Web applications know that reliable scripting needs the document to be parsed by User-Agents without any unexpected error, and will make sure that their markup and CSS is validated before creating a rich interactive layer.
When surveyed, a large majority of Web professionals will state that validation errors is the first thing they will check whenever they run into a Web styling or scripting bug.
Checking that a page “displays fine” in several contemporary browsers may be a reasonable insurance that the page will “work” today, but it does not guarantee that it will work tomorrow.
In the past, many authors who relied on the quirks of Netscape 1.1 suddenly found their pages appeared totally blank in Netscape 2.0. Whilst Internet Explorer initially set out to be bug-compatible with Netscape, it too has moved towards standards compliance in later releases.
Validation is one of the simplest ways to check whether a page is built in accordance with Web standards, and provides one of the most reliable guarantee that future Web platforms will handle it as designed.
It is reasonable to consider that standards such as HTML and CSS are a form of “coding style” which is globally agreed upon. Creating Web pages or applications according to a widely accepted coding style makes them easier to maintain, even if the maintenance and evolution is performed by someone else.
Many professionals have been authoring the Web with HTML and CSS for years and know these technologies by heart. Beginners and students, on the other hands, will find automated checking tools invaluable in spotting mistakes. Some teachers also stress that automated validation tests are a good introduction to broader, more complex quality concepts such as accessibility.
As of today, there is little or no certification for Web professionals, and only few universities teach Web technologies, leaving most Web-smiths to learn by themselves, with varied success. Seasoned, able professionals will take pride in creating Web content using semantic and well-formed markup, separation of style and content, etc. Validation can then be used as a quick check to determine whether the code is the clean work of a seasoned HTML author, or quickly hacked-together tag soup.
Validation, as any process of debugging code, is sometimes difficult, and the vast improvements in automatic error correction has made modern browser cope very well with errors in HTML or CSS. This makes validation seem useless or costly to many people, and the following questions (or statement) are widespread:
The answer to this one is that markup languages are no more than data formats. So a website doesn't look like anything at all! It only takes on a visual appearance when it is presented by your browser.
In practice, different browsers can and do display the same page very differently. This is deliberate, and doesn't imply any kind of browser bug. A term sometimes used for this is WYSINWOG - What You See Is Not What Others Get (unless by coincidence). It is indeed one of the principal strengths of the web, that (for example) a visually impaired user can select very large print or text-to-speech without a publisher having to go to the trouble and expense of preparing a separate edition.
Do remember: household-name companies expect people to visit because of the name and in spite of dreadful websites. Can you afford that luxury?
Even if you can, do you want to risk being on the wrong side of a lawsuit if your site proves inaccessible to - for instance - a disabled person who cannot use a 'conventional' browser? Accessibility is the law in many countries. Whilst validation doesn't guarantee accessibility (there is no substitute for common sense), it should be an important component of exercising "due diligence". It is now just over a year since a court first awarded damages to a blind user against the owners of a website he found inaccessible (Maguire vs SOCOG, August 2000).
That might have been the case a decade ago, when validation was the tool of choice of people more interested in harnessing the power of the markup languages than creating beautiful designs for their content; when many designers were not taught basics of Web technology and would create beautiful but fragile and unreliable web sites.
This argument is completely moot today. In the past decade, most of the stunning, content and design-rich Web sites were built with standard (X)HTML, CSS and scripting.
