Validity - Refactoring HTML: Improving the Design of Existing Web Applications - page 106

Chapter 4. Validity
Validity goes beyond mere well-formedness to ensure that a document is not merely syntactically correct but
semantically correct. It promises that only elements and attributes defined in the HTML specification appear so
that browsers aren't taken by surprise. It also promises that they appear only in certain places where their
meaning is well defined. For example, in a valid document you won't find a table in the head or a blockquote in
a paragraph.
Validity offers many advantages to site authors and even more advantages to site consumers. First, valid sites
are predictable. They show the same content to users with different browsers. Although details regarding font
size and positioning can vary from one browser to another, valid pages are more likely to look reasonably
similar from one browser to the next.
Valid pages convey the same information to different readers, even readers that use such widely varying
interfaces as a graphical browser, an Atom feed reader, or a screen reader. Valid pages are more device-
independent.
Because valid pages are more predictable, you waste less time debugging cross-browser idiosyncrasies. Valid
pages are much easier to make work reliably.
Valid pages are also more future-proof. They are more likely to work reliably in tomorrow's browsers, not just
today's. Weird hacks designed for particular browsers sometimes stop working with a new browser release.
Invalid pages often depend on the subtle bugs and quirks of a particular browser version. Valid pages are more
predictable in browsers you can't even test yet.
In brief, validity is a solid base for future development. Making a site valid will almost always improve a site's
usability, accessibility, speed, and reliability. Most important, it improves a site's maintainability . Valid pages
are easier to upgrade, easier to style, and easier to improve than invalid pages. Valid pages are simply more
robust.
What is true for validity is doubly true for strict validity. Strict validity goes beyond mere validity to also insist
that content be separated from presentation. This makes pages smaller, simpler, and more understandable.
Furthermore, it enables you to use far more powerful CSS techniques to style pages that go well beyond what
you can achieve with simple font tags, spacer GIFs, and table layout.
Validity is not always required. Browsers do build consistent DOMs from merely well-formed documents, and
XML tools can still parse an invalid but well-formed document. However, validity does increase the predictability
of browser display. Just because you can put a table in the head doesn't mean you should.
There are, however, times when you need to violate validity. For instance, if you're adding markup from other
applications such as XForms, MathML, or Scalable Vector Graphics (SVG) to your documents, those documents
will not be valid. The HTML DTDs do not recognize these elements, but you can use them nonetheless. Similarly,
if you're experimenting with HTML 5, the standard DTDs and browsers won't recognize your new elements. And
there are other reasons you might choose to introduce invalid markup.
That being said, if you can make your documents valid, you should. Valid XHTML will help browsers more closely
reflect the author's intent. If you absolutely must publish invalid documents, I suggest that you carefully control
and limit the invalidity. First, make a valid document that leaves out the invalid pieces; then add the minimum
number of invalid pieces you need to accomplish your goals.
As a practical matter, you should usually start by making a document well-formed before making it valid. Often
the distinction is a little fuzzy. For instance, normalizing the case of all tags to lowercase improves both well-
formedness (because start-tags now match end-tags) and validity (because only lowercase element names are
valid). Adding a DOCTYPE declaration is optional for well-formedness, but it is required for validity. You can
even have valid HTML (though not XHTML) that is not well-formed. In general, though, it is simplest if validity