As is appropriate for a web standard, the story of HTML5 starts with the World Wide Web Consortium (W3C), or more precisely, with the W3C Workshop on Web Applications and Compound Documents in June 2004. But rather unusually, the development of HTML5 initially took place outside of the W3C, because the W3C was not at all thrilled with the idea of HTML5 to start with. What had happened?
In a joint position paper, Mozilla and Opera demanded that the W3C should ensure the continued development of HTML, DOM, and CSS as the basis of web applications of the future. Given the fact that the W3C had already sidelined HTML4 six years before and had instead elected to back XHTML, XForms, SVG, and SMIL, it was hardly surprising that this suggestion was rejected. The result was very close, with 8 votes in favor and 11 votes against, but the decision still had far-reaching consequences. In the following years, the development of HTML5 was to take place in direct competition with the W3C.
Ian Hickson, who at the time supported the position paper, together with the second Opera representative Håkon Wium Lie and Mozilla’s David Baron, reviewed the events in his web log and came to the conclusion:
The issues have been discussed, the positions have been given, everyone knows where everyone else stands, now it’s time to get down and actually start doing work.
Referring to recent events, he finishes with these words:
What working group is going to work on extending HTML...
He is referring to the Web Hypertext Applications Technology Working Group (WHATWG), which was created on June 4, 2004, just two days after the end of the workshop. The WHATWG describes itself as a loose, unofficial, and open collaboration of the browser manufacturers Safari, Opera, and Mozilla, as well as interested parties. Its aim is to continue development of the HTML standard and to submit the results of this process to a standards organization to achieve standardization.
The founding members of the WHATWG include Anne van Kesteren, Brendan Eich, David Baron, David Hyatt, Dean Edwards, Håkon Wium Lie, Ian Hickson, Johnny Stenbäck, and Maciej Stachowiak. This select circle of developers from the browser and HTML community was to shape the fate of HTML5 from then on, together with the active WHATWG community.
Three specifications were initially on the agenda of Ian Hickson, who took on a central role as editor: Web Forms 2.0 as advancement of HTML forms; Web Apps 1.0, which focused on application development within HTML; and Web Controls 1.0, a specification centered around interactive widgets. The latter project was soon abandoned, and Web Forms was integrated into Web Apps at a later time. The working method of the WHATWG has always been geared toward collaboration with the community; if you look at the homepage (see Figure 1.1), you can see this very clearly.
Figure 1.1 WHATWG homepage at http://www.whatwg.org
Anyone looking for help with learning or using HTML5 will find answers under FAQ, Help, and Forums. The Wiki, hidden behind the Volunteer button, is not quite as helpful yet, because it is geared more toward development issues and contains little documentation on the HTML5 language. The blog, accessible via the News button, seemed a little neglected in 2010 too, which was perhaps due to the fact that the main author, Mark Pilgrim of Google, was at that time busy writing his own online book, which is freely available at http://diveintohtml5.org in case you want to take a look. Fortunately, Anne van Kesteren resurrected the blog in 2011 with reports on developments of the standard—a valuable source for keeping track of recent changes.
One of the most active areas is the Chat at irc://irc.freenode.org/whatwg, linked via the IRC button. Here, the WHATWG community meets up with browser developers and works with them to implement the specification. This is also the place to have heated debates on matters concerning HTML5, make political statements, or tell critics exactly what you think. An imaginary character, Mr. LastWeek, comments on the events with sometimes hefty blog entries at http://lastweekinhtml5.blogspot.com in reaction to the publicly accessible IRC protocols at http://krijnhoetmer.nl/irc-logs, which anyone can not only read, but also actively comment on. Just click on the yellow box at the end of a line you deem relevant, exciting, or important to color the line yellow. To scan the most recent topics, marking entries works quite well.
Three public mailing lists, linked via the Contribute section, are the main instruments of communication—one for user questions, one for contributions to the specification, and one for all those working on implementing the specification. If you do not want to subscribe to the mailing list, you can also access the public archives where all news items are filed and can be searched or downloaded:
• [email protected]
http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
• [email protected]
http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
• [email protected]
http://lists.whatwg.org/listinfo.cgi/implementors-whatwg.org
The specification is also being developed in a public and transparent manner—more on this topic in a moment; it is not as straightforward as it sounds. In reality, there is not just one specification but several versions of it. But for now, let’s get back to the history of HTML5.
While the WHATWG was working on renewing HTML, the W3C’s XHTML2 Working Group set about creating a completely new web. Unlike the WHATWG, which was aiming to achieve backward compatibility, the XHTML2 Working Group, led by Steven Pemberton, tried to further develop HTML in a different way.
Instead of FORMS
, XFORMS
would be used; FRAMES
would be replaced by XFRAMES
; and new XML Events
would take the place of DOM Events
. Each element could have both a src
and an href
attribute, and the headers h1
, h2
, h3
, h4
, h5
, h6
would be obsolete and be replaced by h
in combination with a new section
element. Manual line breaks with br
would be realized with l
elements; hr
would be called separator
; the new nl
element would allow navigation lists; and to improve semantic options, you could assign a role
attribute with predefined or namespace-extensible keywords to each element.
A drop of bitterness and the final nail in the coffin of the XHTML2 project was the lack of support from the browser vendors. The attempted changes were too radical and did not take existing web content into consideration. Soon, the W3C also came to realize that this development would not get far. In October 2006, Tim Berners-Lee, the director of W3C and inventor of the World Wide Web, finally relented and wrote in his blog:
Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work.
Admitting that XHTML2 had failed to become the new web language, he announced the creation of a new HTML working group—on a wider scale this time. The group would involve the browser vendors and would aim at further developing both HTML and XHTML step by step. In the last paragraph of his blog entry he emphasizes his conviction that this is the right way to go:
This is going to be a very major collaboration on a very important spec, one of the crown jewels of web technology. Even though hundreds of people will be involved, we are evolving the technology which millions going on billions will use in the future. There won’t seem like enough thankyous to go around some days. But we will be maintaining something very important and creating something even better.
In March 2007, the time had come: The new HTML Working Group was formed. Shortly after it had been announced to the W3C, all members of the WHATWG were invited to participate in the HTML WG—an offer the WHATWG gratefully accepted.
A few months later, a vote was taken to decide if the specification drawn up by the WHATWG should become the basis of the new, joint HTML5 specification. In contrast to the vote taken during the Workshop in 2004, the result was in favor, with 43 voting for, 5 voting against, 4 people abstaining, and 1 explicitly rejecting. After a delay of three years, the original idea of further developing HTML had prevailed.
But this was just the beginning: New ways of cooperating had to be found—a task that proved to be anything but easy because the philosophies of WHATWG and W3C were only compatible to a limited extent. The fact that the two camps were not always in agreement was reflected not only in extensive discussion threads in the W3C’s own archived and publicly accessible public-html mailing list (http://lists.w3.org/Archives/Public/public-html), but was also evident in the assessment of the HTML5 project’s road map.
Although the W3C assumed in its Charter that HTML5 would reach Recommendation in Q3 of 2010, Ian Hickson of the WHATWG anticipated a much longer period. The year 2022 has often been suggested, but such a long time span is considered completely unacceptable by many critics. Yet this time frame may seem more realistic if you take into account the ambitious aim of HTML5 to replace the three specifications—HTML4, DOM2 HTML, and XHTML1—and to expand them significantly, to create a test suite with thousands of tests, and to prescribe two faultless implementations of the standard as proof of concept.
One look at the decision-policy rules of the HTML WG gives you an inkling of how complicated the decision-making process of the two groups involved in further developing the specification is (http://dev.w3.org/html5/decision-policy/decision-policy.html). After the XHTML2 Working Group was disbanded in late 2009, the number of critics willing to fully exploit this decision policy increased.
As a result, a constantly growing list of so-called Issues is being tracked by the W3C’s HTML WG (http://www.w3.org/html/wg/tracker/issues). These issues need to be resolved before declaring Last Call under moderation of the chairs Sam Ruby, Paul Cotton, and Maciej Stachowiak. On the part of the WHATWG, Ian Hickson took advantage of a calmer period and was able to temporarily reduce his issues list (http://www.whatwg.org/issues/data.html) down to zero, leading him to announce HTML5 in Last Call to the WHATWG in October 2009.
A visible sign of the complexity of the events is the status of the specification. With the WHATWG, the main specification is a compact document, whereas in early 2011 the W3C had eight parts, all counting as part of the HTML5 package. Two of them are generated directly from the WHATWG version and are marked with an asterisk; the others are supplements and are in turn not contained in the WHATWG version.
WHATWG Specification:
• HTML—Living Standard: http://whatwg.org/html
W3C HTML WG Specifications:
• HTML5 - A vocabulary and associated APIs for HTML and XHTML *: http://www.w3.org/TR/html5
• HTML5 differences from HTML4: http://www.w3.org/TR/html5-diff
• HTML: The Markup Language Reference: http://www.w3.org/TR/html-markup
• HTML+RDFa 1.1: http://www.w3.org/TR/rdfa-in-html
• HTML Microdata: http://www.w3.org/TR/microdata
• HTML Canvas 2D Context *: http://www.w3.org/TR/2dcontext
• HTML5: Techniques for providing useful text alternatives: http://www.w3.org/TR/html-alt-techniques
• Polyglot Markup HTML-Compatible XHTML Documents: http://www.w3.org/TR/html-polyglot
Another WHATWG document exists in which all the WHATWG sections are combined with additional specs for Web Workers, Web Storage, and the Web Sockets API. This document, Web Applications 1.0—Living Standard, is well suited to serve as an endurance test for HTML rendering: With more than 5MB of source code and JavaScript to display the implementation stage of each section, plus the option of adding direct comments to individual sections, it will stretch any browser to its limit:
http://www.whatwg.org/specs/web-apps/current-work/complete.html
Tip
If you want to go easy on your browser, you could either use the multipage version of that document at http://www.whatwg.org/C or add ?slow-browser
at the end of the URL. That way, dynamic components will be skipped and you end up with a static, faster-loading version without interactive elements.
If you want to keep track of the changes made to the specification, you have several options. The WHATWG offers a Subversion repository of the complete specification of which you can create a local copy:
• svn co http://svn.whatwg.org/webapps webapps
You can also access Commit messages of the individual revisions via Twitter, a mailing list, or the web interface, the so-called web-apps-tracker:
• http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
• http://html5.org/tools/web-apps-tracker
Whereas the WHATWG specification changes continuously with each revision, the W3C drafts are subject to the so-called Heartbeat requirement, which means that new versions of the W3C specification must be published at regular intervals of three to four months as Working Drafts. By the time this book is published, the next heartbeat will probably have occurred, and who knows, maybe even a Last Call Working Draft will have been announced by the W3C.
If you want to explore the history of HTML5, the Time Travel section offers a selection of links as portals to milestones and historic events. The article “Why Apple is betting on HTML 5: a web history” offers a very good summary of the entire HTML history. It is available at AppleInsider under the shortened URL, http://bit.ly/2qvA7s.
Milestones in the development of HTML in selected links include the following:
• W3C Workshop on Web Applications and Compound Documents (June 2004): http://www.w3.org/2004/04/webapps-cdf-ws/index
• Position paper by Opera and Mozilla on further development of HTML: http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
• Ian Hickson’s assessment of the workshop in three blog posts: http://ln.hixie.ch/?start=1086387609&order=1&count=3
• Creation of the WHATWG is announced two days after the workshop: http://www.whatwg.org/news/start
• Blog entry “Reinventing HTML” by Tim Berners-Lee (October 2006): http://dig.csail.mit.edu/breadcrumbs/node/166
• Relaunch of the W3C HTML Working Group (March 2007): http://www.w3.org/2007/03/html-pressrelease
• Ian Hickson informs the WHATWG community of the relaunch: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/009887.html
• Official invitation to the WHATWG to sign up for the HTML WG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/009908.html
• Ian Hickson congratulates the W3C on the initiative on behalf of the WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/009909.html
• HTML Design Principles as basis of HTML5 (November 2007): http://www.w3.org/TR/html-design-principles/
• First official HTML5 Working Draft at W3C (January 2008): http://www.w3.org/2008/02/html5-pressrelease
• Announcement that the XHTML2 Working Group will be disbanded (July 2009): http://www.w3.org/News/2009#entry-6601
• WHATWG declares HTML5 at Last Call (October 2009): http://blog.whatwg.org/html5-at-last-call
• W3C publishes eight Working Drafts, two of them new (June 2010): http://www.w3.org/News/2010#entry-8843
• W3C announces Timeline to Last Call, expecting to reach Last Call end of May 2011 (September 2010): http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html
• W3C Introduces an HTML5 Logo (January 2011), causing controversy: http://www.w3.org/News/2011#entry-8992
• Ian Hickson declares that the WHATWG HTML specification will henceforth just be known as “HTML” and can be considered a “living standard” (January 2011): http://blog.whatwg.org/html-is-the-new-html5
After the preceding brief trip through the history of HTML5, the time has come to finally tackle the elements and attributes of HTML5 directly. What could be more appropriate than the classic Hello world! example? This is what it looks like in HTML5:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Hello world! in HTML5</title>
</head>
<body>
<p>Hello world!</p>
</body>
</html>
Every HTML5 document begins with the document type declaration <!DOCTYPE html>
, and it does not matter if you write it in uppercase or lowercase. The second innovation you will notice is the shortened way of specifying the encoding—<meta charset="UTF-8">
. The rest, like html
, head
, title
, or body
, you will be familiar with from HTML4, which leads us to the question: What is really new in HTML5?
The W3C provides the answer with the specification HTML5 differences from HTML4, moderated by Anne van Kesteren. In addition to lists of new and obsolete elements and attributes, we can also find tips on new or changed APIs, external parts of the specification, and finally the HTML5 Changelog, which logs in chronological order how and when individual features have found their way into or out of the specification: http://www.w3.org/TR/html5-diff/.
The tables contain a lot of detail, but do not give us a very clear overview. Four wordles are therefore going to guide us through this chapter. They were all created using Jonathan Feinberg’s Wordle Applet, which is available free of charge at http://www.wordle.net. The frequency of the relevant terms is reflected by the size of the letters for new elements and attributes, and determined by the number of cross-references connected to the relevant feature in the HTML5 specification. For obsolete elements and attributes, the font size corresponds to the frequency of online use, as researched by Opera within the MAMA project What is the Web made of? (http://dev.opera.com/articles/view/mama).
Let’s first take a look at the new elements in the wordle in Figure 1.2. Highlights are definitely the media types video
, audio
, and canvas
—the latter is, simply put, a picture you can program with JavaScript. Many innovations concern structuring elements, for example, article
, section
, header
, hgroup
, footer
, nav
, or aside
. For figures, you have figure
with figcaption
, and you can show or hide additional information with details
in combination with summary
. You can indicate progress with progress
, any kind of measurements with meter
, and time and date with time
.
We are not likely to come across the elements ruby
, rt
, and rp
in English-speaking countries very often; they are a typographical annotation system used mainly in Chinese and Japanese to give guidance on pronunciation. More useful for us is mark
for emphasizing terms or wbr
to show that a line break could be inserted at a certain point if necessary.
Some elements tend toward web applications, such as keygen
for generating key pairs for encryption or digital signatures, command
for executing commands, or output
as a result of calculations in forms or other parts of a document. As a container for option
elements, datalist
offers nonvisible select lists for form fields. For listing alternative resources for video
and audio
elements, there is source
—the browser picks the first known format from this list to play the file. And last but not least is the frequently used embed
element introduced by Netscape, now in an amended version.
The input
element also entails many changes. Here is a brief summary of new types: You now have several new input
types for specifying the date with datetime
, date
, month
, week
, time
, and datetime-local
. Also, there are types for search fields (search
) and for entering URLs (url
), e-mail addresses (email
), telephone numbers (tel
), numbers (number
) or numeric ranges (range
), or colors (color
). As you can see in Figure 1.3, many of the new attributes relate to forms. Thanks to the form
attribute, input elements can be external to the form in question and be, as it were, linked to the desired form. Attributes, such as min
, max
, step
, required
, pattern
, multiple
, or autocomplete
determine restrictions or conditions for input elements, influence the validation of the entered data with formnovalidate
and novalidate
, and offer practical help for filling in forms with placeholder
or autofocus
. What happens when the form is submitted can be overwritten in input
and button
elements with formmethod
, formenctype
, formtarget
, and formaction
. The list
attribute serves to assign selection lists created with datalist
to the relevant input component.
Figure 1.3 New HTML5 attributes
As security features for iframes
, we have sandbox
, srcdoc
, and seamless
. These isolate the embedded content from the rest of the document. If you want to load scripts asynchronously, you can use async
, and ping
opens the list of URLs specified in the ping
attribute in the background whenever you click on a hyperlink.
The manifest
attribute of the html
element seems inconspicuous but has far-reaching consequences: It paves the way for offline web applications by referring to the configuration file determining which parts of the page should be made available offline. The style
elements with the attribute scoped
can also be useful, limiting the validity of the specified styles to the area of the superordinate DOM node and all its child elements. For menu
elements, type
and label
determine the type of menu (for example, context menu or toolbar), plus its label.
Small but sweet improvements include using the charset
attribute in the meta
tag to simplify specifying the encoding; having the option of using li
elements via value
to assign explicit list values; specifying a starting point for ol
with start
; and finally being able to sort lists in reverse order with reversed
.
Some of the global attributes that are valid for all elements have been changed significantly. This does not apply so much to class
, dir
, id
, lang
, style
, tabindex
, and title
, which are now global in contrast to HTML4, but mainly to the new attributes that have been added. With contenteditable
you can now edit elements directly; contextmenu
enables assigning your own menus, defined as menu
; draggable
marks the relevant element as a potential candidate for drag-and-drop actions; and spellcheck
prepares for checking the relevant section for spelling errors.
Contents that are not or no longer relevant at the time of display can be hidden
; the attribute role
or aria-*
can be used to offer additional help for assistive technologies, such as Screenreader; and the reserved prefix data-*
enables you to define as many of your own attributes as you like.
Another important part of HTML5 is that of new programming APIs, for example, the canvas
element API, an API for playing audio and video contents, and an interface for programming offline web applications. Further APIs are devoted to the topics drag-and-drop, editing documents, or governing the browser history. The specification even contains some initially exotic-seeming APIs for registering and applying your own protocols or MIME types.
We should also mention that in HTML5 all event handlers are global attributes and that certain changes were made to the objects HTMLDocument
and HTMLElement
. With getElementsByClassName()
, you can find all elements with a particular class
attribute; you can manipulate class
attributes with the classList
API; and you can now use the method innerHTML
with XML documents, too. You can determine which element in the document is currently in focus with activeElement
and hasFocus
—both as attributes of the HTMLDocument
object, just as with the method getSelection()
, which returns the text currently selected by the user.
When discussing the innovations in HTML5, we should also determine which features we should no longer use. The term deprecated is frequently used in other W3C specifications in this context, but this term is not appropriate in the case of HTML5. Because HTML5 is backward compatible, such features also have to be displayed correctly by the browser. For the author of a web page, however, the specification of differences from HTML4 offers a list of elements and attributes that should or may no longer be used. The term absent now replaces the term deprecated.
If you look at the wordle in Figure 1.4, you can see that the elements font
and center
are definitely out. They are replaced by more up-to-date CSS solutions, and the same applies to the elements u
, big
, strike
, basefont
, and tt
. Now, iframes
replaces frame
, frameset
, and noframes
; instead of acronym
you should now use abbr
, instead of dir
you should use ul
, and isindex
is abandoned in favor of the better options offered by forms. If you are wondering why some of the elements mentioned do not appear in the wordle, this is due to the fact that they were used very infrequently and are therefore no longer part of HTML5.
Figure 1.4 Elements no longer used in HTML5
For obsolete attributes, the picture is equally clear. Dominant in the wordle in Figure 1.5 are width
, height
, alignment (align
, valign
), spacing (cellpadding
, cellspacing
), and coloration (bgcolor
). They appear mostly in combination with table
, td
, or body
and are now replaced by CSS, like many of the obsolete elements.
Figure 1.5 Attributes no longer used in HTML5
How do we know in detail which elements and attributes should no longer be used? It would be very time-consuming to have to keep searching through the HTML5 differences. A better solution is offered by the HTML5 validator at http://html5.validator.nu: The validator knows exactly what is right and wrong. Let’s give it a try: We select Text Field as input mode and replace the line <p></p>
in the preset HTML basic frame with the following wrong markup:
<center>
<acronym>WHATWG</acronym>
</center>
The error messages this returns look like this—at least at the time of this writing:
1. Error: The center element is obsolete. Use CSS instead.
2. Error: The acronym element is obsolete. Use the abbr element instead.
The link in Use CSS instead leads us directly to the WHATWG Wiki, to the page Presentational elements and attributes, where we can read details regarding correct use. The validator also shows syntax errors directly, as you can see in the next test. Let’s try the following source code:
<!DOCTYPE html><title>
We get another error message in answer—this time with the comment that the document is not yet complete and therefore invalid:
1. Error: End of file seen when expecting text or an end tag.
If we fix this error by adding the end tag </title>
, this error message disappears as well and we have created the shortest possible HTML5 document:
<!DOCTYPE html><title></title>
Error recognition in the validator is based on one of the key features of HTML5, the HTML parser. Unlike all previous specifications, it was formulated to the last detail, and with its 90 pages is about as exciting to read as the local phone book. From a technical point of view, however, this chapter is essential, because it defines how the HTML5 markup should be parsed and how the document’s DOM tree should be structured.
Our preceding mini example generates in reality a complete HTML5 DOM tree, including html
, head
, and body
elements. You can prove this with another tool, the HTML5 Live DOM Viewer, at http://livedom.validator.nu. Give it a go!
The HTML5 specification basically defines an abstract language for describing documents and web applications with APIs for interaction, which are representable in an in-memory DOM tree. It does not matter which syntax is used as the basis for creating this DOM tree—HTML is one of them, and XHTML is another. What matters is always the result after parsing, which is a valid DOM-HTML tree in both cases.
So the decision whether to use HTML or XHTML when creating documents is up to the author. HTML is more widely used, easier to write, more forgiving with small syntax errors, and requires the MIME type text/html
for output. XHTML follows the strict XML rules (keyword well-formedness) and always has to use an XML MIME type, such as text/xml
or application/xhtml+xml
, which was not the case previously with XHTML 1.1.
The Hello world! example in XHTML5 manages without DOCTYPE
but does require a valid XML declaration instead, which can be wrapped up in the encoding, and of course it has to be well-formed:
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Hello world! in HTML5</title>
</head>
<body>
<p>Hello world!</p>
</body>
</html>
You probably cannot see much difference between this and the HTML version. That is due to the fact that we have not made full use of the permitted level of simplification in HTML code for the first Hello world! example. In lazy HTML5, this markup would have been sufficient:
<!DOCTYPE html>
<meta charset=utf-8>
<title>Hello World! in HTML5</title>
<P>Hello world!
We can leave out quotation marks for attributes if the attribute value does not contain any spaces or any of the symbols " ' > / =
. Tags can be written in uppercase or lowercase; sometimes they can even be omitted as in the preceding example. If you are not sure, the validator can once again help you out. Regarding implementation of the new HTML5 parser, Mozilla has taken the lead. Henri Sivonen’s Parser, which is also the basis of http://validator.nu, is included with Firefox 4.
Yes and no. HTML5 is not finished yet by any stretch of the imagination, but unlike previous practice, the development of the HTML5 standard is taking place hand in hand with its implementation. Who would have thought that Internet Explorer 9 (IE9) would offer SVG and Canvas, or that Google would start offering HTML5 videos on YouTube? Many of the new features can be used now, provided you can choose your browser. HTML5 can be used in a company’s internal intranet as well as on your private homepage that only selected friends can access.
With Firefox, Chrome, Opera, and Safari, four great browsers are already supporting a wide range of HTML5, and IE9 has finally ended Microsoft’s long hesitation in supporting web standards in 2011. Browser manufacturers and their developers are now actively participating in forming the standard. They implement new specification drafts first in test versions as proof of concept and then post their feedback and suggestions for improvements in the WHATWG or the W3C. This makes them important parts of the development cycle. Anything that cannot be implemented is removed from the specification, whereas other components are adapted and finally implemented.
Early adopters of HTML5 are well advised to familiarize themselves with the individual browser’s release notes, as trends in response to the question What will come next? will most likely emerge here:
• https://developer.mozilla.org/en/HTML/HTML5
• http://www.opera.com/docs/changelogs
• http://googlechromereleases.blogspot.com
• http://ie.microsoft.com/testdrive/info/ReleaseNotes
The timeline of the development of HTML5-relevant specifications in combination with the milestones of browser releases indicate with their shorter and shorter release intervals that standardization and implementation are closely linked (see Figure 1.6).
Figure 1.6 Timeline of specifications and browser releases
It will be interesting to see how the two areas continue to develop. You can find an up-to-date version of the timeline at the following URL:
http://html5.komplett.cc/code/chap_intro/timeline.html?lang=en
This chapter begins with a bit of historical background and then provides a high-level overview of the changes the HTML5 specification brings to web development. In addition to a look behind the scenes of the specification development, our main focus is on the long list of new elements, attributes, and APIs. Two brief Hello world! examples demonstrate the basic frame of a website encoded in HTML5 and XHTML5, and last but not least we address the question: Can I start using HTML5 now? The answer is yes, albeit with minor reservations. But now we will move on to the practical application of HTML5. Let’s first start with a big chunk of innovations: more structure and semantics for documents!