Validating HTML5 Documents

The following is an extract from our book, HTML5 & CSS3 for the Real World, 2nd Edition, written by Alexis Goldstein, Louis Lazaris, and Estelle Weyl. Copies are sold in stores worldwide, or you can buy it in ebook form here.

In the previous chapter, we introduced you to a number of syntax changes in HTML5, and touched on some issues related to validation. Let’s expand upon those concepts a little more so that you can better understand how validating pages has changed.

The HTML5 validator is no longer concerned with code style. You can use uppercase or lowercase, omit quotes from attributes, exclude optional closing tags, and be as inconsistent as you like, and your page will still be valid.

So, you ask, what does count as an error for the HTML5 validator? It will alert you to the incorrect use of elements, elements included where they shouldn’t be, missing required attributes, incorrect attribute values, and the like. In short, the validator will let you know if your markup conflicts with the specification, so it’s still a valuable tool when developing your pages.

To give you a good idea of how HTML5 differs from the overly strict XHTML, let’s go through some specifics. This way, you can understand what is considered valid in HTML5:

Some elements that were required in XHTML-based syntax are no longer required for a document to pass HTML5 validation; examples include the html and body elements. This happens because even if you exclude them, the browser will automatically include them in the document for you.

• Void elements (that is, elements without a corresponding closing tag or without any content) aren’t required to be closed using a closing slash; examples include meta and br.

• Elements and attributes can be in uppercase, lowercase, or mixed case.

• Quotes are unnecessary around attribute values. The exceptions are when multiple space-delimited values are used, or a URL appears as a value and contains a query string with an equals (=) character in it.

• Some attributes that were required in XHTML-based syntax are no longer required in HTML5. Examples include the type attribute for script elements, and the xmlns attribute for the html element.

• Some elements that were deprecated and thus invalid in XHTML are now valid; one example is the embed element.

• Stray text that doesn’t appear inside any element but is placed directly inside the body element would invalidate an XHTML document; this is not the case in HTML5.

• Some elements that had to be closed in XHTML can be left open without causing validation errors in HTML5; examples include p, li, and dt.

• The form element isn’t required to have an action attribute.

• Form elements, such as input, can be placed as direct children of the form element; in XHTML, another element (such as fieldset or div) was required to wrap form elements.

• textarea elements are not required to have rows and cols attributes.

• The target attribute for links was previously deprecated in XHTML. It’s now valid in HTML5.

• As discussed earlier in this chapter, block-level elements can be placed inside link (a) elements.

• The ampersand character (&) doesn’t need to be encoded as & if it appears as text on the page.

That’s a fairly comprehensive, though hardly exhaustive, list of differences between XHTML strict and HTML5 validation. Some are style choices, so you’re encouraged to choose a style and be consistent. We outlined some preferred style choices in the previous chapter, and you’re welcome to incorporate those suggestions in your own HTML5 projects.

Summary

By now, we’ve gotten our heads around just about all the new semantic and syntactic changes in HTML5. Some of this information may be a little hard to digest straight away, but don’t worry! The best way to become familiar with HTML5 is to use it—start with your next project. Try using some of the structural elements we covered in the last chapter, or some of the text-level semantics we saw in this chapter. If you’re unsure about how an element is meant to be used, go back and read the section about it, or better yet, read the specification itself. While the language is certainly drier than the text in this book (at least, we hope it is!), the specs can provide a more complete picture of how a given element is intended to be used. Remember that the HTML5 specification is still in development, so some of what we’ve covered is still subject to change in the new HTML5.1 version (or in the HTML5 “living standard,” if you go by the WHATWG’s definition). The specifications will always contain the most up-to-date information.

In the next chapter, we’ll look at a crucial segment of new functionality introduced in HTML5: forms and form-related features.