New features in HTML5
The HTML5 specification includes a series of new semantic elements that is used to give some meaning to the various sections or parts of a Web page, such as a header, footer, navigation, and so on. In previous versions of HTML, you would typically use <div> elements to create these parts, using ID or class attributes to differentiate them from each other. The problem with this is that this has no semantic meaning, as there are no strict rules defined that specify what class names or IDs are to be used, making it extremely difficult for software to determine what the particular area is doing. HTML5 should help alleviate these issues, making it easier for Web browsers to parse the semantic structure of a document.
It is worth pointing out that continuing to use <div> elements in HTML5 is perfectly valid, but in order to future-proof your work, it is recommended that you use semantic elements where relevant. On the other side of the coin, it is also suggested that you avoid using these new elements for purposes other than their intended. For example, the <nav> element should not be used for just any group of links; it is intended to surround the main navigation block on the page.
The main semantic elements that HTML5 introduces are:
- This element is used to define a header for some part of a Web page, be it the entire page, an <article> element, or a <section> element.
- Like the <header> element, this new element defines a footer for some part of a page. A footer does not have to be included at the end of a page, article, or section, but it typically does.
- This is a container for the primary navigation links on a Web page. This element is not intended for use with all groups of links and should be used for major navigation blocks only. If you have a <footer> element that contains navigation links, you do not need to wrap these links in a <nav> element, since the <footer> element will suffice on its own.
- The <article> element is used to define an independent item on the page that can be distributed on its own, such as a news item, blog post, or comment. Such items are typically syndicated using RSS feeds.
- This element represents a section of a document or application, such as a chapter or a section of an article or tutorial. For example, the section you are reading now could be surrounded by a <section> element in HTML5. <section> elements typically have a header, although it is not strictly required. The header for the section you are reading now would contain the text "Semantic elements," for example.
- This new element can be used to mark up a sidebar or some other content that is considered somewhat separate to the content around it. An example of this might be advertising blocks.
- In some cases, a page, article, or section may require more than one heading, such as where you have a title and a subtitle. This tutorial, for example, has the title "Create modern Web sites using HTML5 and CSS3" and the subtitle "Implementing the canvas and video elements in HTML5." You could wrap these in an <hgroup> element, using an <h1> element for the main title and an <h2> element for the subtitle.
The sample Web site at the end of this tutorial includes several of these new semantic elements, and I will explain their syntax and use in more detail at that point.
The <canvas> element was originally developed by Apple® for use in Mac OS X Dashboard widgets and in Safari, but was later adopted by Mozilla® and Opera® in their Web browsers. The element has been standardized and included in the HTML5 specification, along with a series of 2D drawing APIs that can be used to create shapes, text, transitions, and animations inside the element.
Many believe that the <canvas> element is one of the most important aspects of HTML5 as it facilitates the production of graphs, interactive games, paint applications, and other graphics on the fly without requiring external plug-ins such as Adobe Flash.
In recent years, the popularity of video sharing sites such as YouTube and content delivery platforms like Hulu has seen a huge explosion in the use of the Web for multimedia streaming. Unfortunately, the Web was not built with such content in mind, and as a result, the provision of video and audio has by and large been facilitated by the Flash Video (.flv) file format and the Adobe Flash platform.
A key issue with these new multimedia elements, however, is the file formats supported by each browser and the patent licensing issues that go along with the various codecs that these files can be encoded with. Mozilla and Opera want to use the open source Theora video container and codec, which does not require patent licensing for the inclusion of the codecs in the Web browser. On the other hand, Apple and Google are not happy with the quality of Theora, particularly for the delivery of high definition (HD) content on the likes of YouTube. They prefer the H.264 codec, typically contained in MP4, MOV, or MKV files.
The issue is not just with video however, as the same problems reside with audio codecs. The MP3 and AAC formats are restricted by patents, whereas the Vorbis format is not. The problem with Vorbis audio is that it is not in widespread use, as portable media players and many media software applications do not support it.
There are many decisions to be made about HTML5 <video> and <audio> in the near future, and it will be interesting to see what codecs and formats are facilitated in the final recommendation. In the meantime, you can try to support all browsers by making video available in a variety of formats and by providing Flash video as a fallback. Let's hope that a final decision is made, and that it is not left to browser vendors to decide which formats to support, as that would essentially render these new elements useless.
Again, you will see the <video> element in action later in this tutorial.
Web developers have traditionally used cookies to store information on a visitor's local machine, allowing a Web page to read this information back at a later point. While cookies are very useful for storing basic data, they are limited by the fact that Web browsers are not required to keep more than 20 cookies per Web server or more than 4KB of data per cookie (including both name and value). In addition, they are sent to the Web server with every HTTP request, which is a waste of resources.
HTML5 provides a solution for these problems with the Local Storage APIs, which are covered in a separate specification to the main HTML5 document. This set of APIs allows developers to store information on the visitor's computer while remaining reasonably confident that they will still be there at a later date. In addition, the information is accessible at any point (even after the page has rendered) and is not loaded automatically with each HTTP request. The specification includes same-origin restrictions, which prevent Web sites from reading or changing data stored by other Web sites.
Most browsers store Web pages in local cache, allowing them to be viewed even if the user is offline. This works fine for static pages, but it is not available for dynamic content that is typically database-driven, such as Gmail, Facebook, or Twitter. HTML5 provides support for offline applications, where the browser downloads all the files necessary to use the application offline, and when the user uses the application offline, the browser can allow any changes made in the process to be uploaded to the server when they reconnect to the Internet.
If you have created Web applications before, you are more than likely familiar with HTML's set of form controls, some of which are implemented using the <input> element. In HTML 4, the following input types were supported:
In addition, there are some other elements that are used in forms such as <select> and <textarea>. These form controls provide plenty of function for basic form fields such as name, phone number, and address—like you might find on a contact form. But, the Web as a platform has grown far beyond the stage where HTML forms are used to submit contact forms—now they are used to submit application data for server-side processing. As a result, Web application developers find themselves continually in need of some more sophisticated form controls, such as spinners, sliders, date/time pickers, color pickers, and so on.
At the moment, support for these new form fields is quite limited. The Mobile Safari browser on the iPhone makes use of some of these new types to change the type of keyboard presented to the user (for example, with the e-mail type, the @ symbol and .com shortcuts will be shown). Also, Opera provides some new widgets for many of these controls, including a spinner for the number type and a calendar date picker for the date-related types. The most widely available type of these new offerings is the range type, which is rendered as a slider by Opera, Safari, and Google Chrome.
Figure 1. The placeholder attribute in action
As Figure 1 shows, the placeholder text for e-mail address and phone number appears in grey, while the field is empty and does not have focus. This screenshot also shows an example of a range input type, represented here by a slider in the Safari browser. This screenshot is taken from the sample Web page discussed later in this tutorial.
HTML5 includes so many new features; it's impossible to cover them all in this tutorial. This section provides a brief overview of some of the other enhancements in the specification.
- Web worker
- HTML5 includes a geolocation API that allows a Web application to determine your current geographical location, assuming the device you are targeting provides features for finding such information (for example, GPS on a cellphone). If you do not have a device that supports this feature (such as an iPhone or an Android 2.0-based smartphone), you can use Firefox and download a plug-in that allows you to set your location manually.
- Drag and Drop
- Cross-document messaging
- This allows documents in different windows (and iframes, for that matter) to send and receive messages to one another. This feature could prove very useful for the development of widgets and applications that are hosted on servers other than the primary Web page's server (similar to Facebook applications).
- And more