Preface
HTML5 is the new catchall term for the Web. Like Ajax and Web 2.0 before, the term can cause confusion when used in different contexts. HTML5 is technically the fifth revision of the HTML markup language, but you will find the term being used to describe an umbrella of next-generation web technology specifications that include CSS3, SVG, and JavaScript APIs.
In order to understand HTML5 in this context, first it is important to understand that HTML5 is not one technology that is applied or added to a web application. There are more than 30 specifications within the HTML5 umbrella, and each is at a different stage of maturity. Furthermore, each specification is also at a different state of adoption and, potentially, implementation, by the major browser manufacturers.
Depending on an applications business requirements, the apps developer will pick and choose the HTML5 features to take advantage of. It is entirely possible that only a handful of the available specifications will be used for the final implementation of a modern web application.
Critics often proclaim it is necessary to wait until HTML5 is 100% supported before you use it in your application. This is simply not true. Many specifications have already reached maturity and are fully implemented by modern browsers. Other specifications are at an early stage of development, or are poorly supported by some of the major browser manufacturers. Its important to know which specification type you are using. Research is helpful, but the only true way to tell is to thoroughly test your apps in all browsers.
For the specifications that are newer or that arent as strongly supported, some clever developers have produced free and open source code that can be utilized to shim, or polyfill , support in older browsers. As defined by Remy Sharp, A polyfill, or polyfiller, is a piece of code (or plug-in) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape, if you will. In our opinion, the best polyfill is one that lets you write your code just as you would if the feature were natively supported, and that does the work in the background when necessary, being transparent to both the user and the developer. In most circumstances, each HTML5 specification has a polyfill, or multiple competing polyfills, and is ready to be used today. You will find references to some of the Webs most effective polyfills within this book.
Hack #1. Why HTML5?
A beginning developer might ask, Why should I care about HTML5? Unfortunately, there is not a simple answer to this question. Even the most advanced web developers will answer this question differently depending on the features they are most familiar with.
But overall, there are some common trends that span the feature set and on which most developers would agree. Before HTML5, the Web was not considered to be a rival to native desktop and mobile applications. Nearly since its inception, the Web has been considered to be an easily deployable, cross-platform solution. However, it has been hampered due to its lack of highly important business requirements: namely, performance, security, and graphics. The theory has been that if the modern web browser could mature as an application platform, developers would be able to stop creating platform-specific native applications.
The Ajax revolution took the web application world in the right direction by providing asynchronous, background updates to the server via the XMLHttpRequest
object, JSON transfer format, and an explosion of JavaScript libraries that stretched the boundaries of application development in the browser, many of which continue to make up the basis for polyfill support. However, HTML5 is about the modern browser providing the necessary support to enable sophisticated application development natively. In order to accomplish this, features such as the ability to maintain browser history and bookmarking during asynchronous interactions, cross-domain communication, local storage, offline support, rich graphics, and even new protocols to improve the speed and efficiency of the connectivity layer still needed to be created and improved.
Browser prefixes are most common in CSS. We urge you to read the introduction to to get a full explanation of how browser prefixes are implemented in CSS.
HTML5 Implementations
As an eager developer ready to move forward with implementing some of the new features available in this text, it will be important to understand that many of the HTML5 specifications are in experimental stages of development. One major challenge in writing a book about evolving specifications is keeping the information fresh and up to date.
The following topics are important considerations when learning experimental web browser specifications.
Browser-specific prefixes
In order for browser makers to be able to implement experimental features (usually implementing specifications before they were completed), browser makers prefix that feature with a shorthand that limits its use to each particular browser. A great example of this is the implementation of requestAnimationFrame
, which is a JavaScript method in the page that aids in animation within the browser. Each browser originally implemented this feature with browser prefixes as follows:
Browser prefixes are most common in CSS. We urge you to read the introduction to to get a full explanation of how browser prefixes are implemented in CSS.
Validation with HTML5 Conformance Checker
An HTML validator is a piece of software that parses your web pages against a set of web standards as defined by a particular Document Type Definition (DTD). If you are unfamiliar with a DTD, think of it as metadata that precedes your HTML markup in order to instruct the browser as to what flavor of HTML you will be using.
The HTML validator returns a list of errors found, according to the chosen standard. For our purposes, we will assume that we are using the HTML5 Document Type Definition.
The HTML5 Document Type Definition is more lenient than the most recent XHMTL definition, and the output of the W3C's new validator reflects this difference. After all, a validator should not throw exceptions for stylistic issues. It should be focused on validating your HTML markup against a specification.
HTML5 Lint
This means that developers should also be ready to use a lint tool in order to expose stylistic issues within their code. Some of the more common issues to check for are consistent indentation, lowercase tags, and omission of closing tags.
At the time of this writing, we recommend the HTML5 Lint tool.
References for HTML5 implementation statuses and feature support
We will continue to provide updates as often as possible to the examples provided within this text on our blog.
There are also many great resources around the web to reference HTML5 implementation statuses and feature support of specific browsers.
For all modern browsers:
http://caniuse.com/ |
http://html5test.com/ |
For Chrome:
http://www.chromium.org/developers/web-platform-status |
For Internet Explorer: