Copyright © 2017 Shlomi Fish
This document is copyrighted by Shlomi Fish under the Creative Commons Attribution Unported License ( CC-by ) version 4.0 (or, at your option, any greater version).
For securing additional rights, please contact Shlomi Fish and see the explicit requirements that are being spelt from abiding by that licence.
To educate the world about the benefits of making sure their markup of HTML and other Web and non-Web languages is valid according to the web standards.
Most web browsers will accept various variations in the HTML markup language, but often will not know exactly what to do, unless the markup is well-formed and strictly abides by the WWW standards. To make it easier for browsers, for other HTML consumers and processors, and for general good measure, one should make sure the HTML validates and thus is valid.
By validating your pages, you make sure the structure of the document is acceptable to standards-compliant browsers.
When you deviate from the standard, you don't know how the browser is going to react.
Saying that “I don’t know if my site is standards compliant or not, but it looks good in all browsers.” (or just in one browser and one platform on which it was tested) is not a good idea.
The browsers may not display this page correctly in future versions, or a new browser may do things differently.
(For instance, when Microsoft Internet Explorer (MSIE) version 5.0 came, it was more standards-compliant than MSIE 4.x and as a result many sites that worked with IE before became broken. This happened in the release of MSIE 6.0, and in Windows XP Service Pack 2, as well.)
The browser has a tough job as it is, so you shouldn't make it tougher by sending it mal-formed input.
Standards-compliance is not a panacea.
Even if all the output from the site is standards-compliant. it doesn't mean it will display correctly.
This is either because of bugs in the browsers, or because you have not done the right thing.
So, it is important to test the pages in as many browsers as possible, in addition to validating them.
A DuckDuckGo search for “html validator” as well as a Google search will yield many results. Note that you should first choose a version of the HTML or XHTML standards (such as HTML5 or XHTML5) and use their correct Doctype to indicate that you are using them. Different HTML pages (even ones on the same site) may adhere to different versions of the standards, and validate accordingly, as long as they specify the appropriate doctypes.
HTML Tidy - a library and a command-line program for validating and fixing HTML. It is recommended to run it with all warnings displayed.
WWW Markup Validation is a specific case of “linting” where one runs a program to make sure bad idioms are not present in one’s code or markup. There are links to more linters and checkers below.
Also see "awesome linters" on GitHub which lists many good linters.
Perl Elements to Avoid and “What are some best practices in programming that I should adopt?” - mention other good practices.
tidyall - an all-in-one linter, validator and tidier.
check-all-the-things - another all-in-one checker, this time from the Debian project.
Mozilla Developer Network (MDN) - Recommended reference and tutorials for Web technologies.
HTML Dog - Recommended HTML, CSS, and JavaScript tutorials.
List of tools for static code analysis - on Wikipedia.
Canonical URL for the document - on Shlomi Fish’s home site. That page should validate as XHTML5.
GitHub repository - contains the DocBook sources, an issue tracker and more resources. Contributions are welcome. Currently, that page does not validate, but it appears to be GitHub’s fault.