An HTML5 FAQ — SitePoint

After this quick introduction to HTML5 markup, you probably have a bunch of questions swirling in your head. Here are some answers to a few of the likely ones.

Why do these changes still work in older browsers?

To understand why this isn’t a problem, we can compare HTML5 to some of the new features added in CSS3, which we’ll be discussing in later chapters.

In CSS, when a new feature is added (for example, the border-radius property that adds rounded corners to elements), that feature also has to be added to browsers’ rendering engines, so older browsers will fail to recognize it. If a user is viewing the page on a browser with no support for border-radius, the rounded corners will appear square. This happens because square corners are the default and the browser will ignore the border-radius declaration. Other CSS3 features behave similarly, causing the experience to be degraded to some degree.

Many developers expect that HTML5 will work in a similar way. While this might be true for some of the advanced features and APIs we’ll be considering later in the book, it’s not the case with the changes we’ve covered so far; that is, the simpler syntax, fewer superfluous attributes, and the new doctype.

HTML5’s syntax was more or less defined after a careful study of what older browsers can and can’t handle. For example, the 15 characters that comprise the doctype declaration in HTML5 are the minimum characters required to make every browser display a page in standards mode.

Likewise, while XHTML required a lengthier character-encoding declaration and an extra attribute on the html element for the purpose of validation, browsers never actually required them in order to display a page correctly. Again, the behavior of older browsers was carefully examined, and it was determined that the character encoding could be simplified and the xmlns attribute removed—and browsers would still see the page the same way.

Unlike changes to CSS3 and JavaScript, where additions are only supported when browser makers actually implement them, there’s no need to wait for new browser versions to be released before using HTML5’s markup syntax. And when it comes to using the new semantic elements, a small snippet of JavaScript is all that’s required to bring any really old browsers into line.

Note: Standards Mode versus Quirks Mode

When standards-based web design was in its infancy, browser makers were faced with a problem: supporting emerging standards would, in many cases, break backwards compatibility with existing web pages that were designed to older, nonstandard browser implementations. Browser makers needed a signal indicating that a given page was meant to be rendered according to the standards. They found such a signal in the doctype: new standards-compliant pages included a correctly formatted doctype, while older nonstandard pages generally didn’t. Using the doctype as a signal, browsers could switch between standards mode (in which they try to follow standards to the letter in the way they render elements) and quirks mode (where they attempt to mimic the “quirky” rendering capabilities of older browsers to ensure that the page renders how it was intended).

It’s safe to say that in the current development landscape, nearly every web page has a proper doctype, and thus will render in standards mode; it’s therefore unlikely that you’ll ever have to deal with a page rendered in quirks mode. Of course, if a user is viewing a web page using a very old browser (such as IE4), the page will be rendered using that browser’s rendering mode. This is what quirks mode mimics, and it will do so regardless of the doctype being used.

Although the XHTML and older HTML doctypes include information about the exact version of the specification they refer to, browsers have never actually made use of that information. As long as a seemingly correct doctype is present, they’ll render the page in standards mode. Consequently, HTML5’s doctype has been stripped down to the bare minimum required to trigger standards mode in any browser. Further information, along with a chart that outlines what will cause different browsers to render in quirks mode, can be found on Wikipedia. You can also read a good overview of standards and quirks mode on SitePoint’s CSS reference.

Shouldn’t all tags be closed?

In XHTML, all elements were required to be closed—either with a corresponding closing tag (such as html) or in the case of void elements, a forward slash at the end of the tag. Void elements are elements that can’t contain child elements (such as input, img, or link).

You can still use that style of syntax in HTML5—and you might prefer it for consistency and maintainability reasons—but adding a trailing slash on void elements is no longer required for validation. Continuing with the theme of “cutting the fat,” HTML5 allows you to omit the trailing slash from such elements, arguably leaving your markup cleaner and less cluttered.

It’s worth noting that in HTML5, most elements that can contain nested elements—but simply happen to be empty—still need to be paired with a corresponding closing tag. There are exceptions to this rule (such as p tags and li tags), but it’s simpler to assume that it’s universal.

What about other XHTML-based syntax customs?

While we’re on the subject, omitting closing slashes is just one aspect of HTML5-based syntax that differs from XHTML. In fact, syntax style issues are completely ignored by the HTML5 validator, which will only throw errors for code mistakes that threaten to disrupt your document in some way.

What this means is that through the eyes of the validator, the following five lines of markup are identical:

<link rel="stylesheet" href="css/styles.css" />
<link rel="stylesheet" href="css/styles.css">
<LINK REL="stylesheet" HREF="css/styles.css">
<Link Rel="stylesheet" Href="css/styles.css">
<link rel=stylesheet href=css/styles.css>

In HTML5, you can use lowercase, uppercase, or mixed-case tag names or attributes, as well as quoted or unquoted attribute values (as long as those values don’t contain spaces or other reserved characters), and it will all validate just fine.

In XHTML, all attributes were required to have values, even if those values were redundant. For example, in XHTML you’d often see markup like this:

<input type="text" disabled="disabled" />

In HTML5, attributes that are either “on” or “off” (called Boolean attributes) can simply be specified with no value. So, the aforementioned input element can be written as follows:

<input type="text" disabled>

Hence, HTML5 has very loose requirements for validation, at least as far as syntax is concerned. Does this mean you should just go nuts and use whatever syntax you want on any given element? No, we certainly don’t recommend that.

We encourage developers to choose a syntax style and stick to it—especially if you are working in a team environment where code maintenance and readability are crucial. We also recommend (though this is optional) that you choose a minimalist coding style while staying consistent.

Here are some guidelines for you to consider using:

Use lowercase for all elements and attributes as you would in XHTML.
Despite some elements not requiring closing tags, we recommend that all elements containing content be closed (as in <p>Text</p>).
Although you can leave attribute values unquoted, it’s highly likely that you’ll have attributes that require quotes (for example, when declaring multiple classes separated by spaces, or when appending a query string value to a URL). As a result, we suggest that you always use quotes for the sake of consistency.
Omit the trailing slash from void elements (such as meta or input).
Avoid providing redundant values for Boolean attributes (for instance, use <input type="checkbox" checked> rather than <input type="checkbox" checked="checked">).

Again, these recommendations are by no means universally accepted; however, we believe that they’re reasonable syntax suggestions for achieving clean, easy-to-read maintainable markup.

If you do run amok with your code style, including too much that’s unnecessary, you’re just adding extra bytes for no reason. You’re also potentially making your code harder to maintain, especially if you work with other developers on the same code base.

htmlcss2thumb

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.