Introduction

Hypertext Markup Language (HTML) is a core language for creating and structuring web pages. For more than 20 years developers have been writing HTML, and for the first few years the language underwent radical changes, but in the late 1990s things slowed down a bit. Until now.

A Brief History of HTML

In 1991 Sir Tim Berners-Lee wrote a document called “HTML Tags,” which described 20 elements that would be used for writing web documents. By mid-1993 the Internet Engineering Task Force (IETF) had published a proposal for the first HTML specification. The proposal draft expired, and it was not until November 1995 that the first specification was published: not HTML 1.0, but HTML 2.0.

HTML 3.2 was released in 1997, and this was followed up by HTML 4, published in 1998. HTML 4 had three variations: Strict, Transitional, and Frameset. During this period, browser vendors, such as Microsoft and Netscape, started implementing HTML in slightly different ways, and we had our first round of browser wars (http://en.wikipedia.org/wiki/Browser_wars).

XHTML

After the release of HTML 4, the World Wide Web Consortium (W3C) decided to stop the evolution and development of HTML and work on Extensible Hypertext Markup Language (XHTML) 1.0, an XML-based language that was considered the future of the Internet. There were no new elements in XHTML—in fact, the specification was the same as HTML 4—but developers had to conform to new syntax rules: Tags had to be closed, or self-closed, and attributes had to be quoted. This required stricter, tighter coding standards and ensured that developers would be using a single style of writing. Around this time in 2001, Cascading Style Sheets (CSS) started becoming more prominent and popular, and with the rise of blogging, the increased awareness of web standards was significant.

Beginning in 2002, the W3C released drafts of XHTML 1.1. While XHTML 1 was essentially HTML with a splash of XML, XHTML 1.1 was essentially XML. Although it was supposed to be more forward-thinking, it was not backward compatible, so if it was used in website development, the website would not work in current and older browsers.

This caused concern among the web community, with browser vendors, and even within the W3C itself. Not everyone was convinced that XML was the future markup of the web.

Web Forms, Web Apps, and the WHATWG

In 2004, individuals from Apple, Mozilla, and Opera began working on their own specification, aiming at creating backward-compatible code that could be used to create web applications. W3C rejected this proposal, and this led to a group being formed calling itself the Web Hypertext Application Technology Working Group (WHATWG).

The WHATWG began working on Web Forms 2.0 and Web Applications 1.0. The editor for the specifications is Ian “Hixie” Hickson, and issues and ideas are raised via a public mailing list. Although initially there was work on two specifications, Web Forms 2.0 and Web Applications 1.0, they have now been merged into one specification, called HTML5.

XHTML 2 versus HTML5

So, while WHATWG was developing HTML5, over at the W3C, the XHTML 2 specification was languishing. In 2006, the W3C decided that it had made the wrong decision in abandoning HTML in the previous years, and although it would still develop XHTML 2, it would once again look at the development of HTML. The W3C decided to use the work done so far by WHATWG as the starting point for a new version of HTML.

Although this was positive news, it also led to a confusing state because there were now currently three different types of markup being worked on: two by the W3C, HTML 5 and XHTML 2; and one at the WHATWG, HTML5 (notice there is no space compared to the W3C “HTML 5”). So, with HTML5/HTML 5, the specification was being developed at the same time but by two groups.

WHATWG operates in a very different manner than the W3C, and it is able to move at a much faster pace. Because of the public mailing list at WHATWG, ideas were put forward regularly, and web developers were able to question some of the decisions made. The specification team was, and still is, able to implement good ideas, reject bad ideas, and change or remove items of the specification based on community feedback quickly. HTML5 was developing much quicker at WHATWG than at the W3C.

After a couple of years of this, in 2009, the W3C announced it had stopped work on XHTML 2. HTML5 had “won.”

So, where does that leave the specification? Well, it is still being developed primarily by the WHATWG, while the W3C then takes the specification and puts it through review.

The process has not exactly been perfect, but there are exciting outcomes.

Which Specification Should I Be Looking At?

There is a version of the specification at the W3C (http://dev.w3.org/html5/spec/spec.html) and one at the WHATWG (http://whatwg.org/specs/web-apps/current-work/multipage/). Both are huge, heavy documents. In March 2011, Ben Schwarz launched the “WHATWG HTML5 specification for web developers” (http://developers.whatwg.org), which we suggest using. You can also keep up-to-date with the specification via the mailing list if you are interested in the daily discussions: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org.

The base HTML5 specification is just that, a base. A major shift has occurred to match the speed at which the technology is growing. New add-on specifications are being worked on all the time by teams in both the WHATWG and the W3C, and they include features such as network connection information and device camera information. Browser vendors are working together to help define these features and fast track the inclusion of the functionality into their browsers. The next couple years will prove to be very exciting.

The Principles of HTML5

HTML5 has been created in a way that supports existing content or, in other words, is backward compatible. The major concern over the proposed XHTML2 specification was that it would break the majority of websites. HTML5 has been built on the foundations of HTML 4, so browsers can continue to support HTML, not just new HTML5 elements but all of the things that are in HTML 4. Sites that work now in HTML 4, or XHTML, are expected to work fine in HTML5.

Using HTML5 means you can continue to code in the style that you have used previously. We will cover this more in Chapter 1, but HTML5 has been written with developers in mind, so you can keep using HTML syntax or XHTML syntax, and browsers will know what to do.

HTML5 also tells the browsers how it should handle errors caused by incorrect markup implementation. Previously, browsers would interpret the errors themselves, and thus each browser would have its own quirks. HTML5 has been written for developers like us and for browser vendors so that in the not too distant future, we are all working to and from the same standard.

Perhaps the true power of HTML5 is how it addresses the needs for web application developers. Because browsers are so powerful, we can create websites that are very much like applications: They can provide photo sharing, drawing, file editing, and other features. Previously, these features required layers of JavaScript and a plug-in such as Java or Flash. But this meant accessibility issues and relied on the stability of third-party software. HTML5 gives us new standards for how we can create web applications, with powerful APIs for things such as canvas for drawing, drag and drop, offline storage, and native video in the browser. With specified standards, browsers will handle these things correctly and in a stable fashion over time. The web community will help develop and grow the standards, continuously pushing and improving them, and developers will not have to create hacks to get these features to work.

What Exactly Is HTML5?

HTML5 is not just one technology. It is more of an umbrella term that has been adopted for the inclusion of new and enhanced HTML elements, CSS styles, and JavaScript APIs and events. The intersection of these technologies provides for a wide range of new features to enhance the user experience, make websites more like native applications, and integrate to devices. The following are just some of the new or
enhanced functions available:

• Improved semantics

• Forms

• Canvas drawing

• Drag and drop

• Local storage

• Page-to-page messaging

• Desktop notifications

• Video and audio

• Web sockets

• Geolocation

• History

• Microdata

Although not strictly part of the HTML5 specification, geolocation is a cool, new technology being developed at the same time, so it gets talked about in the same breath as HTML5. And yes, we are going to talk about geolocation in this book as well.

Not everything new in web development is HTML5. CSS3 is not HTML5, but because it is new and very cool, it gets put in the same category as HTML5. CSS is a completely different language and technology than HTML. CSS is presentation; HTML is structure. You can do some pretty awesome things with CSS3, but developers and the community should be aware that there is a difference.

And although we do not want to get into a debate over whether HTML5 is a Flash killer (it’s not), the bottom line of HTML5 is that there is now an incredible amount of functionality built directly into the browser, and it is all standard.

Does HTML5 Have a Logo?

Yes, HTML5 sure does have a logo. In years gone by, web developers and site owners have put icons on their site showing that they adhere to various W3C guidelines, such as (X)HTML, CSS, or accessibility. This trend has cooled down a bit recently, but in early 2011 the W3C released a series of logos, which initially caused quite a stir in the web community because it grouped many web technologies, including CSS3, under the HTML5 umbrella. As mentioned, CSS3 is not HTML5, but with the W3C seemingly admitting otherwise, the web community raised its concerns.

Thankfully, the W3C changed its aim and definition of the logos, so the main logo (Figure I.1) “represents HTML5, the cornerstone for modern web applications,” and the smaller logos (Figure I.2) “represent aspects of modern web applications and web sites—style, semantics, graphics, and so forth.”

Figure I.1 The HTML5 logo (The HTML5 logo is attributed to the W3C, www.w3.org)

Figure I.2 Smaller icons representing different technologies: (from left to right) Device Access; 3D, Graphics & Effects; CSS3; Semantics; Multimedia; Connectivity; Performance & Integration; and Offline & Storage

So, the logos are there for developers who want to show support for the key web standards. The use of the icons or logo is not required, but they are available if you would like to use them to show your adoption of the various features. The logos are available from http://w3.org/html/logo, and there is a logo builder available so you can select different icons and styles.

The Cookbook Style

This book is designed to be a show-by-example text and follows the cookbook style of providing a topic explanation and recipes that support the topic. The recipes in most cases attempt to show how the technology might be applied to real-world coding problems, rather than showing an example that has no real purpose. Like a recipe used in the kitchen, it is our hope that you will find these recipes valuable starting points for your own programming solutions.

In general, the book has been laid out to cover simpler topics in the beginning, building on these topics to more complex subjects later. We include HTML5 elements and CSS3 additions in early chapters and migrate to various JavaScript APIs and events in later chapters. We know that for any one of these topics a whole book could be written on all the intricacies. This is the case especially with topics such as CSS3, and there are many good books available.

For each topic covered in a chapter, we have included a table that shows the level of support for the feature across common browsers. We have included one or more recipes showing how the technology can be employed. In most cases, the recipes have a series of instructions, the code listing or listings, and then a walk-through of the recipe. Each recipe has also been posted on the book website: www.HTML5DevelopersCookbook.com.

Recipes are divided into three categories: Beginner, Intermediate, and Advanced. These categories are meant to provide some sense of the difficulty of the topic covered, while trying to also provide some sense of the amount of effort and time you may need to allocate to complete the recipe. These are broad categorizations, and the time and effort required we know will vary greatly by reader.

Third-Party Libraries

If you have been involved in web development for any amount of time, one of the first things you will notice about the recipes in this cookbook is that very few recipes leverage third-party libraries of JavaScript such as jQuery and the myriad other libraries available. There are a few minor exceptions to this where we specifically address support by third-party libraries or integrations to address hurdles that the libraries may solve. In general, though, we have tried to focus on the core HTML5 technology since each reader will have their own favorite set of libraries to use and each library will have its own level of support and integration methods for HTML5 features.

We firmly believe libraries play an important role in the daily web design and development of sites and applications. We have our own favorite libraries as well. In many cases, the libraries that have already integrated many of the HTML5 features are integrating them in a similar manner to how they are defined. So, understanding how to use the component in generic JavaScript will allow you to more easily leverage the component in the library of your choice.

HTML5DevelopersCookbook.com

By nature, a cookbook of this type is full of code listings that support the recipes. Because of how fast the HTML5 technology is being expanded, it is essential that the book have a companion website to keep the material up to date. The www.HTML5DevelopersCookbook.com website has been set up for this purpose and has not only electronic versions of the recipes and supporting files available for execution and download but also additional resources.

When Will HTML5 Be Ready for Use?

There is the common concern that developers cannot or should not start using HTML5 right now, but that is not the case.

Do I Have to Wait Until 2022?

No, you do not have to wait until 2022! In a 2008 interview, HTML5 editor Ian Hickson gave a timeline that HTML5 would not be ready until 2022. This was blown out of proportion in the media and web community. What we believe Hickson meant was that the final proposed recommendation will not be released until around 2022, but that does not mean you cannot put to use all the features that have already been defined and incorporated. As you might have gathered from the discussion of the history of HTML, specifications take an incredible amount of effort and time, and a specification has many stages it needs to go through before it is finished.

A popular argument involves the status of CSS 2.1. CSS 2.1 has been in development for more than 10 years, and only in the summer of 2011 was it finalized, but in the years while it was being developed, we all still used CSS, didn’t we? We are now at CSS3, and who knows when that will be “ready.” This is a prime example of how the web community is pushing the technology and future of the web ahead of the specifications.

So, Can I Use HTML5 Now?

Yes, you can use HTML5 now! There will not be a time when you have to stop using HTML 4 and start using HTML5. Who knows when the W3C will announce that HTML5 is officially ready; we may all be employing HTML6 features by that point. But the browser manufacturers are embracing HTML5 features wholeheartedly and incorporating new features all the time.

Because there are so many different sections and technologies within the specification and add-on specifications, you can pick and choose the parts of HTML5 you want to incorporate; it is not a case of all or nothing. Not all browsers play nice 100 percent of the time, but in Chapter 3, Browser Handling in HTML5, we explain some methods of browser handling. The latest versions of Firefox, Safari, Opera, Chrome, and Internet Explorer all support a wide range, albeit slightly different sets, of HTML5 features. However, day by day, and even during the writing of this book, we have seen significant improvements across the browsers, and this will only continue as browsers remain competitive.

So, grab yourself a text or HTML editor, a handful of browsers, and get plugged in to some HTML5.