Chapter 1

HTML5: Now, Not 2022

Congratulations, you’ve reached Chapter 1! Your journey through the evolution of the Web is about to begin. This chapter establishes the basic principles. Its focus, along with the rest of the first half of this book, is mostly HTML5. We’ll cover how HTML5 came about, what problems it aims to solve, what design principles have guided its development, and what new features it brings to the table. We’ll also debunk some HTML5 myths. We’ll start off, however, by looking at the basic tenets we follow in our web development work, why standards are so important, and why we should strive to make our markup universally accessible and well crafted.

It’s a roller coaster ride of ups and downs, but it’s an exciting journey. Without further ado, let’s get started…

Basic tenets

The information in this book is built on a number of strongly held principles: the importance of open web standards, the craft of well-structured semantic markup, and a firm belief that well-written HTML is a part of the design process. Our solid HTML structure should be styled with CSS (an approach we’ll cover when we look at separation of layers later in this chapter).

A web standards approach

The movement towards a standards-driven Web has been thanks in no small part to the Web Standards Project, or WaSP (http://j.mp/webstandardsproject1). In the late ’90s, Internet Explorer and Netscape were fighting to gain supremacy of the Web in a period known as “the browser wars.” This was a horrible time, as these rivals were trying to win users over by introducing countless new features that were incompatible across browsers. The result was sites that either only worked in one browser or had two different versions to support both the major players. This was a nightmare for web developers, and it hurt the users.

Founded in 1998, WaSP campaigned for standard implementations across the different browsers and a standards-based approach to web design. The aims were to reduce the cost and complexity of web development and to increase the accessibility of web pages by making web content more consistent and more compatible across devices and assistive technologies. They lobbied browser and tool vendors to improve support for web standards recommended by the World Wide Web Consortium (W3C), such as HTML and CSS.

And they had a lot of success. Skip forward to the modern day, and web standards are consistently implemented across all major browsers. Although you do still get the occasional weird bit of browser behavior, it is miles better than it was. Let’s now take a brief look at what web standards actually are.

What are web standards?

We use standards on a daily basis, often without realizing it. When we buy a light bulb, for example, we know that if we buy a screw-in or bayonet bulb, it will fit our light fittings when we get it home. Standards ensure that the bulb we buy isn’t just a little too large or just a little too wide to fit our light fixture. Standards are all around us: look at the plugs in your home, the power rating of your appliances, and the time, distance, and temperature measurements used by everything in our society.

Web standards pick up from the same principle. As browser manufacturers and web developers have moved toward embracing standards, the need to write browser-specific markup has diminished. By using well-structured HTML to mark up content and CSS to control presentation, we should now be able to design one web site that will display consistently across standards-compliant browsers regardless of operating system (although the occasional quirk still exists). Equally importantly, when the same markup is rendered by less-capable, non-standards-compliant browsers—in older text-based or mobile browsers—the content should still remain accessible. Web standards save us time as designers and allow us to sleep at night, safe in the knowledge that our carefully crafted masterpiece is accessible regardless of who’s viewing it on which browser and which platform.

__________

Why use web standards?

Perhaps a better question to ask is, “Why ignore web standards?” The benefits of adopting a web standards approach are so compelling, why wouldn’t you use them?

The benefits of using web standards include the following:

• Cuts down on development time: You can build a single site that will work across all platforms, browsers, devices, etc. Without standards, you’d probably have to develop a different site for each browser, etc.
• Creates sites that are easy to update and maintain: With web standards and best practices, you can, for example, update a single CSS file to change styling for a whole site of many HTML pages. Before this was the norm, we used to put the styling information inside the HTML, which meant changing the information on every page. This was really repetitious and inconvenient.
• Improves search engine rankings: The content inside HTML is text-based and therefore readable by search engines. In addition, writing good copy and using semantic HTML (like headings) appropriately can give more weight to appropriate keywords and send your pages shooting up the Google charts.
• Improves accessibility: Well-written HTML and CSS makes web sites more accessible to diverse user groups such as people with disabilities, people using mobile devices, people on low bandwidth connections, etc.

Now that we’ve got a clear insight into the main benefits of a web standards approach, let’s take a look at two principles we’ll be looking at in depth in this book: the importance of semantic markup and the infamous web trifle.

Semantic markup

We believe in the importance of semantic markup (sometimes called POSH for Plain Old Semantic HTML). We believe that HTML is a design element and that, before adding a presentational layer (which enhances the underlying markup), it’s important to focus on building a solid foundation of well-structured content.

Semantic markup is self-describing and uses the correct HTML elements for the correct job. For example, you could mark up a heading like this:

It would look like a heading, sure, but it would not function as a heading in terms of meaning or purpose. Therefore, it would have a negative effect on search engine optimization (keywords in headings have more weight), accessibility (screen readers use heading elements as navigational signposts), development (it is a lot trickier to target elements with styles and scripts when you don’t use proper semantic elements), and more.

It’s much better to use the proper element, like so:

Semantic markup should also be as lightweight as possible, which means removing all those nested <divs>and other spaghetti code. This makes file sizes smaller and coding easier.

Now that we understand the importance of crafting a solid HTML foundation, it’s time to meet the Web trifle.

The web trifle: separating those layers

Everyone loves a trifle, especially at Christmas.

Andy Clarke, writing in Stuff &Nonsense (http://j.mp/stuffandnonsense2) in 2005, took the metaphor of the humble trifle to new heights when he used it to describe the “Web Standards Trifle,” a heady mixture of sponge, fruity jelly, custard, cream, and the all-important topping. You can read his original post at http://j.mp/standardstrifle3. Most of it still hold true today.

The essence of what he is saying is that you should separate your data structure, styling information, and scripting/behavior into separate layers.

• Semantic HTML provides the data structure, a clean, easy-to-access set of content. HTML5 provides this nicely. You should make this data as accessible and usable as possible, without any styling of scripting enhancements.
• CSS provides the styling information, which takes our data and gives it the visual presentation we desire. CSS3 provides more powerful tools than its predecessor, CSS2.
• JavaScript (including the base language and scripting APIs defined inside HTML5 and elsewhere) provides the scripting/behavior layer, which adds usability enhancements and richer functionality to our sites.

The Dao of web design: embracing uncertainty

The browser landscape is rapidly evolving. However, unlike the Wild West days of the browser wars, today’s landscape is evolving and converging towards standards. Firefox, Safari, Opera, Chrome and, of course, our old friend IE are all—admittedly at different rates—moving forward towards supporting all the new standard features inside HTML5, CSS3, etc. Many web developers are also moving towards web standards and their associated best practices, although many are being left behind.

__________

But we’ve now got a new type of uncertainty to worry about: we no longer just have desktop browsers to support. There’s a rapid growth of people accessing the Web on the go via mobile devices, tablets, TVs, games consoles, and more. The explosion of devices like Apple’s iPhone and iPad, Google Android devices, Blackberrys, the Wii, DS, and Philips and Sony web-enabled TVs has given way to a significant rise in the number of people accessing the Web while on the move, in the living room, and away from their desks.

Opera, creators of Opera Mini (one of the world’s most popular mobile browsing platforms), reports significant growth year-on-year (and month-on-month) in users browsing the Web while on the go. This looks set to grow exponentially with the inexorable rise of smartphones.

With so many different devices upon which to consume web content, it is becoming harder and harder to predict exactly what your site will look like across all your user’s devices. Rather than obsessing about having pixel-perfect control, we need to embrace the uncertainly and design flexible sites that adapt to different browsing contexts.

This is by no means a new idea. John Allsopp’s “The Dao of Web Design,” published on A List Apart way back in 2000, stressed the importance of web designers learning to let go, learning to live with the complexity—and uncontrollability—of the Web, and embracing the lack of control that is an inherent part of the complex world of web delivery we design for. Underlining the variables that come into play when designing for the Web (screen size, resolution differences, monitor depth, installed fonts, etc.), Allsopp encouraged web designers at the turn of the millennium to embrace the inherent unpredictability of web design and to design for a Web that lacked the precise control of print media.

Encouraging web designers to look through “the other end of the microscope,” he reframed the “control” of print design as a “limitation,” stating “the fact we can control a paper page is really a limitation of that medium.” Read that again; it’s a subtle but important point.

Fast forward to today and this view isn’t quite so unusual. The fluidity of the Web is celebrated by many more people these days. You will still meet many designers and clients who obsess about print-design pixel perfection on the Web, but it is easier to convince them that the fluid way is right, especially now that browsing devices are more varied than ever before.

Dan Cederholm’s 2007 site, Do Web Sites Need to Look the Same in Every Browser (Figure 1-1), answers the question clearly with a resolute “No!”

Figure 1-1. Do web sites need to look the same in every browser? No!

As Allsopp puts it, web designers aren’t controllers and the Web is not print. This is a fundamental shift. For designers used to the fixed frame of reference that is typical of the world of print, this can take a great deal of getting used to. Allsopp reiterates, “as designers we need to rethink this role, to abandon control, and seek a new relationship with the page.”

Rethink the lack of control; stop seeing it as a weakness, and see it as a strength. This is the key point of Allsopp’s piece. As he puts it, “make pages which are adaptable.” Why? Because adaptable is accessible. As Allsopp puts it, think about “designing the universal page.”

This next quote reinforces what we said earlier about semantic HTML: “Where HTML provides an appropriate element, use it. Where it doesn’t, use classes.” Simple. HTML is, despite the tendency of many lazy designers to over-rely on needless class attributes, a rich and comprehensive semantic language, so we should use it to our full advantage.

And, as we’ll see when we look at HTML5 in upcoming chapters, there are richer semantic elements at our disposal and thus need to rely even less on classes in the future. If anything, our task looks to get easier. Good times!

Accessibility

Accessibility, sometimes shortened to a11y (a numeronym, or number-based word: “a, then 11 letters, then y”), should be a fundamental of our approach. Embracing the Dao of web design brings with it a number of benefits including wider accessibility to a broader, more diverse audience.

Key to this is considering how different users use the Web. Some people use it just like you do. Some people use different devices or have slower web connections. Some people only use the keyboard. Some people user screen readers to read web pages out to them. Some people can’t hear audio content. Whatever you do, familiarize yourself with a diverse population of web users. Don’t just assume everyone else uses the Web exactly like you.

We think that accessibility is AGoodThing™ so don’t be surprised to see us highlighting some of the benefits (and potential pitfalls) that HTML5 brings to the accessibility party.

Crafting your markup

We’re firm believers in the emphasis on craft in web design and web development. Paying attention to details is important, as is taking pride in one’s work, even when writing markup.

In his excellent book The Craftsman, Richard Sennett writes about the craftsmen involved in the creation of Linux, stressing their focus “on achieving quality [and] on doing good work.” Closer to the world of web design, Dan Cederholm in Handcrafted CSS states

The details are not always obvious. With a well-made piece of furniture, you might not notice how well made it is until you start using it. Pull out the drawer and notice the dovetail joints, for instance.

All of this can be related to web design. Seemingly non obvious details can often separate good web design from great web design. You might not appreciate the quality of a well-designed web site until you start using it, looking under the hood, putting it through tests.

We completely agree with Mr Cederholm. The difference between good web content and great web content is craft, taking the extra time to dot the i’s and cross the t’s—paying attention to the details.

As the world of web design evolves, we increasingly find ourselves collaborating with others and working within teams. A solid, well crafted approach to markup—based on agreed rules and standards—can considerably enhance collaboration, streamlining the process and (we’d even go so far as to say) making it more enjoyable.

We feel craft is important, and we’re sure you do, too.

How was HTML5 created?

You may ask yourself, well, how did I get here?

-- Talking Heads, “Once in a Lifetime”

HTML5 is just one point in a long line in the development of HTML that has seen a variety of flavors with different specifications. Though they might have differed in their details, every flavour of HTML had one fundamental aspect in common: HTML is a markup language.

Yes, HTML 4.01 and XHTML 1.0 might differ in coding style, but they share this common goal. With the differing, and often strongly voiced opinions from the two—at times opposing—camps that support them, it’s often been easy to lose sight of the common ground.

HTML5 in many ways represents the best of all worlds, with a great deal of new potential thrown in for good measure, as you’ll see later. Before we introduce HTML5 and its different facets, let’s do a very brief recap of how we found ourselves where we are now.

Beyond HTML 4…

HTML4 had nothing wrong with it, really. It was a perfectly good spec, and the technology was perfectly fine for doing the job it was originally intended for: marking up static documents with links in between them. But things never sit still. Web developers weren’t happy to just carry on making static documents for the rest of their lives. They wanted to make dynamic web sites that behaved more like applications than pages and were starting to do that using technologies like PHP, JavaScript, and Flash.

Hence the need for evolution.

XHTML 1.0

It was actually all the way back in 1998, around the time when the HTML4 spec was nearing completion, when the decision was made by the W3C to move the Web towards XHTML and not HTML (see http://j.mp/futuremarkup4). They then drew a line under HTML4 (the last version was actually 4.01, which included some bug fixes and the like) and instead concentrated on the XHTML1.0 spec.

In August 2002, the W3C commented that

The XHTML family is the next step in the evolution of the Internet. By migrating to XHTML today, content developers can enter the XML world with all of its attendant benefits, while still remaining confident in their content’s backward and future compatibility.

With this rallying call, it was no surprise that when considering how best to evolve HTML, the W3C initially threw its weight behind XHTML (note the word “initially”). XHTML1.0 seemed like a sensible move. It was basically just HTML4 reformulated as an XML vocabulary, which brought with it the stricter syntax rules of XML (for example, attribute values must have quotes around them, elements need to be closed). The goal was better quality, more efficient markup.

XHTML 2.0 and the backlash

However, the next move the W3C made didn’t go down so well. The next version of XHTML, XHTML2.0 was created with a somewhat utopian approach. it contained some great ideas and was a well-written spec, but it simply didn’t reflect what web developers were actually doing on the Web. It was more of what the W3C would like them to do ideally.

Also, it was not backward compatible with the content already on the Web. A lot of the features worked differently; for example, the XHTML mimetype (application/xhtml+xml) did not work at all on IE, and the developer tools available weren’t ready for working with XML

The community was dismayed at this and a backlash occurred. Most notably, in 2004 a group of like-minded developers and implementers (including representatives from Opera, Mozilla, and slightly later, Apple) banded together to form a renegade spec group called the WHATWG (www.whatwg.org) that aimed to write a better markup spec with a more effective set of features for authoring the new breed of web applications and without—crucially—breaking backwards compatibility.

The WHATWG created the Web Applications 1.0 specification (http://j.mp/webappliactions15), which documented existing interoperable browser behaviors and features as well as new features for the Open Web stack such as APIs and new DOM parsing rules. After many discussions between W3C Members, on March 7, 2007 the work on HTML was restarted with a new HTML Working Group in an open participation process. One of the first decisions of the HTML WG was to adopt the Web Applications 1.0 spec and call it HTML5.

The WHATWG and the W3C now develop the HTML5 spec in tandem with two different specs.

__________

• The WHATWG HTML spec (http://j.mp/html5-current6) is a place for contributors to rapidly create and work on innovative new features, way before they might make it into an official recommendation. Note that the version number has been dropped; this is a living standard that will continue to evolve as a single entity, free of versioning.
• The W3C HTML5 spec (http://j.mp/w3c-html57) is where the most stable, agreed-upon features are documented. This version paints a truer picture of where we are in terms of what features are most complete and most likely to be supported in browsers.

Google’s Ian Hickson was until recently the editor of both specs. He is somewhat of a “benevolent dictator” and not everyone agrees with the way he works. But he does an admirable job of dealing with all the feedback he receives about the specs and generally keeping things sane—no easy task indeed for documentation of such magnitude.

HTML5 moving forward!

HTML5 has succeeded where XHTML2.0 failed because it has been developed with current and future browser development and past, present, and future web development work in mind. As a result, it’s gained significant momentum. Driven by pragmatism, it has emerged as the W3C’s choice for Accelerated Development. John Allsopp summarised it best:

One of the lessons the Web continues to teach us is that it values pragmatic development over theoretical perfection.

HTML5 is backwards compatible. It contains all the features of the HTML4 spec, albeit with a few changes and improvements. But it also contains much more extra stuff for building dynamic web applications and creating higher quality markup, such as:

• New semantic elements to allow us to define more parts of our markup unambiguously and semantically rather than using lots of classes and IDs.
• New elements and APIs for adding video, audio, scriptable graphics, and other rich application type content to our sites.

__________

• New features for standardising functionality that we already built in bespoke, hacky ways. Server-sent updates and form validation spring to mind immediately.
• New features to plug gaps in the functionality we traditionally had available in open standards, such as defining how browsers should handle markup errors, allowing web apps to work offline, allowing us to use always-open socket connections for app data transfer, and again, audio, video and scriptable images (canvas).

HTML5 has been deliberately built to compete with proprietary plug-ins such as Flash and Silverlight. It looks like such technologies are increasingly taking a back seat. And as you’ll see as you move through this book, a lot of HTML5 has good support across all modern browsers and therefore is usable right now in your production projects. It can even be made to work in older browsers with a bit of JavaScript coaxing.

HTML5 is so cool that it’s even got its own logo; see http://j.mp/html5-logo8. This W3C publicity campaign was one of many (with Apple, Microsoft, and others providing similar outreach) designed to get developers interested in adopting the new language and popularizing HTML5 as a buzzword as well as a set of technologies.

The trouble with most of these initiatives is that they were confusing in terms of defining HTML5. If you look at the W3C page just mentioned, you’ll see that it lists many different technologies as being part of HTML5, including many that really aren’t (CSS3 and SVG being the most glowing examples). CSS and SVG are completely different technologies from HTML with completely different purposes! We would like to advise you to take care not to confuse the different technologies in conversation, as it makes communication more difficult, especially when you are talking to less technical members of a web team (such as project managers and marketers).

So, now we know that the browser support is there, and we’ve covered some of the history leading up to the emergence of HTML5. Let’s take a look at some of the principles that have guided the development of the specification. We mentioned some of these already, but now let’s go into a bit more detail.

HTML5 design principles

HTML5 is guided by a number of design principles designed to support existing content while paving the way for the new approaches to markup. Among others, the W3C defines these principles as follows:

• Ensuring support for existing content.
• Degrading new features gracefully in older browsers.
• Not reinventing the wheel.
• Paving the cow paths.
• Evolution, not revolution.
• Enabling universal access.

__________

Unlike XHTML 2.0, HTML5 takes a pragmatic approach to markup, favoring a “real world” approach over the utopian approach adopted by those developing XHTML 2.0 (the approach that ultimately led to its demise). This pragmatic approach allows us to use HTML5 now, safe in the knowledge that it’s been designed with moving forward in mind.

Let’s take a look at some of the principles outlined by the W3C in “HTML Design Principles” (http://j.mp/html-design-principles9) and explain what they mean in practice.

Supporting existing content

The Web celebrated its 21st birthday in 2011. Its phenomenal growth is unparalleled in history and has resulted in billions of web pages in existence already. At the heart of the development of HTML5 lies the importance of supporting all of this existing content.

HTML5 isn’t about sweeping out the old and replacing it lock, stock, and barrel with something new. It’s about keeping what we already have and adding enhancements on top. With this in mind, the W3C states that

It should be possible to process existing HTML documents as HTML5 and get results that are compatible with the existing expectations of users and authors, based on the behavior of existing browsers.

In short, as HTML5 takes hold, consideration will be given to how existing content designed and developed using older versions of HTML will be handled.

Degrading gracefully

In line with supporting existing content, as HTML5 evolves, the W3C HTML design principles ensure that thought is given to how older browsers handle new elements. With this in mind, the W3C states that

HTML5 … should be designed so that web content can degrade gracefully in older or less capable user agents, even when making use of new elements, attributes, APIs and content models.

A key part of this principle lies in giving consideration to “user agents designed to meet specific needs or address specialized markets, such as assistive technologies,” thereby aiding and improving accessibility. No bad thing.

__________

Don’t reinvent the wheel

As you’ll see in Chapter 3 when you learn how the new elements HTML5 introduced came to be named, the design of HTML5 gives consideration to what has gone before. The W3C places a heavy emphasis on not reinventing the wheel, or to put it less formally, “If it ain’t broke, don’t fix it.”

The W3C states that

If there is already a widely used and implemented technology covering particular use cases, consider specifying that technology in preference to inventing something new for the same purpose.

If you’ve been working on the Web for some time and embracing web standards, this means that—by design—most of what you’re accustomed to informs the development of HTML5 and you shouldn’t need to relearn everything.

Paving the cowpaths

Paving? Cowpaths?

Essentially this phrase means that if a path or a way of working has evolved naturally and is in widespread use among developers, it’s better to work with it than to replace it. Embrace and adopt the de facto standards in the official specs. Again, we’ll see how this design principle has been put into practice in Chapter 3 when we look at the origin of the new element names introduced in HTML5.

Evolution, not revolution

As the W3C put it,

Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don’t have to learn new models and content will live longer.

In practice, this should mean less of a requirement for existing designers and developers to relearn everything. Again, a good thing.

So now we know who is driving forward the development of HTML5 and the guiding principles. It’s time to wrap up this chapter with a spot of myth-busting.

A dozen myths about HTML5

Now that you’ve had a brief history of HTML and we’ve introduced the context surrounding the development of HTML5, it’s time to dispel a few myths and refute a few untruths. HTML5 is plagued with rumour but a lot of this is flatly untrue. Let’s bust some myths.

1. Browsers don’t support HTML5

One misconception about HTML5 is that browser support for HTML5 is too unpredictable to start using the specification now. As we said earlier, this isn’t the case. The proliferation of books on HTML5 since 2010—by a cross-section of respected authors—clearly indicate that browser support exists and that the time for HTML5 is now, not 2022.

When mainstream sites like Newsweek (http://newsweek.com) and YouTube (http://youtube.com) are beginning to wholeheartedly embrace HTML5, clearly you can, too. (That’s why you’re reading this book, after all!)

2. OK, most browsers support HTML5, but IE surely doesn’t

Given our good friend IE’s historical idiosyncrasies when it comes to all things standards related, you might be forgiven for thinking this was the case. This time, however, it’s not true. Reviewing IE9 in June 2010, The Web Standards Project stated

We’ve been really impressed so far. IE9 really puts the oft-maligned browser on par with the remainder of the browser landscape and even gives them the edge in certain cases. Hats off to the IE team, this is great work.

When IE is singled out for praise, you know the times they are a-changin’. IE9 and IE10 have introduced support for many HTML5 features, such as <video>, <audio>, <canvas>, HTML5 semantic elements, and more.

3. HTML5 won’t be finished until 2022

Again, not true. The mythical date of 2022, taken from an Ian Hickson interview (http://j.mp/hixie-interview10) is for a final Proposed Recommendation status.

Given that this is something we still don’t have for CSS 2.1, a technology that we’re all using every day, it’s clear that the 2022 date resolves around a semantic issue (specifically how one defines the term “finished”).

__________

4. Now I have to relearn everything!

Not at all. As you’ve already seen in this chapter, at the heart of HTML5 development lie the twin concepts of embracing evolution, not revolution (evolving existing standards rather than replacing them) and paving the cowpaths (using established tried-and-tested practices to build on).

Most of what you’ve learned to date simply integrates into HTML5.

5. HTML5 uses presentational elements

At first glance, you might be forgiven for thinking this, but look a little closer and you’ll see this isn’t the case. Yes, the HTML5 specification lists elements like <small>, previously admonished for being presentational. Taking this element as an example, it’s been redefined. <small> is no longer presentational (meaning “display this at a small size”). It’s now semantic, meaning “this is the small print.”

6. HTML5 is a return to tag soup

No, certainly not. HTML5 includes new semantic elements that will allow us to streamline our markup further, not bloat it.

7. HTML5 kills accessibility kittens

There are huge efforts to ensure that new HTML5 features are accessible moving forward (and to protect kittens). No need to worry. And HTML5 allows us to write accessible markup in just the same way that HTML4 always did.

8. Flash is dead

Not really, no. It is true that proprietary technologies are taking more of a back seat these days in many contexts, due to open standards now providing a lot of the same functionality, and that a lot of Flash developers are moving over to open standards, but it will still have its uses for a few years to come.

9. HTML5 will break the Web!

Absolutely not. As discussed already, HTML5 is backwards compatible, and we’re already seeing well-known commercial sites being kitted out with HTML5 features.

10. HTML5’s development is controlled by browser vendors

Again, not true. Although the WHATWG was established by browser vendors, the process of agreeing the development of HTML5 is open to all. Yes, the browser vendors are innovating rapidly, but everyone can have a say, you included.

11. HTML5 includes CSS3, Geolocation, SVG, and every other modern technology under the sun

No! There is still a great deal of confusion about what HTML5 is and isn’t. As Bruce Lawson of Opera puts it, “Like ‘Ajax,’ HTML5 has become a bit of an umbrella term [with] people lumping all kinds of unrelated technology like SVG, CSS3, JavaScript, Geolocation, even webfonts in with it.” It’s true. Many designers confusingly refer to CSS3 as being “a part of HTML5.” It isn’t. This is another thing we aim to clear up in this book. If you are unsure whether a feature is part of HTML5 or not, look it up in the spec.

Bruce created the following diagram to help us out with defining the Web ecosystem: http://j.mp/lawson-html5-sketch11.

12. So when can I start using HTML5?

Right now!

Summary

So ends our introduction to HTML5. We hope this has set the scene nicely on where front-end web development is going and given you a thirst to learn more and update your skillset! In this chapter, we covered the web standards approach; the most important web design principles; the importance of semantic markup and separation of layers; the modern web browser landscape; accepting uncertainty; and embracing accessibility. We also looked at the history and origins of HTML5, the design principles guiding its development, and what problems it aims to solve. And we rounded our tour off by debunking some HTML5 myths.

__________

Homework

One of the principles of this book is that we use homework to ensure the reader understands the principles of each chapter. At the end of each chapter we’ll set you some tasks to complete that are mapped to the content covered in that Chapter.

For some of the Chapters we have provided example content that can be downloaded from the accompanying website http://thewebevolved.com. If you get stuck at any point or require further advice please do not hesitate to contact us authors via the website. Good luck!

Chapter 1 homework

For Chapter 1, it’s simple: We’ve provided you with some content about Gordo (a monkey who proved to be a pioneer in the space race), that some of you may have met from HTML and CSS Web Standards Solutions: A Web Standardistas’ Approach further adventures (download it from http://thewebevolved.com).

We’ve structured it to look like typical content with a mix of headings, paragraphs, a blockquote or two, and some lists. In short, it’s the kind of thing you encounter every day.

Your first task is to mark up the content provided using your current flavor of choice (XHTML 1 or HTML 4.01). You’ll use the results of this homework in Chapter 2 to compare and contrast how your current flavour of HTML relates to HTML5.

Directed reading

It’s a testament to the rapid rise of HTML5 that not only are there a number of vanguard books being published on it, but a number of freely accessible web sites exist with reference material and tutorials.

We recommend the following resources:

• http://html5doctor.com: It should come as no surprise to see HTML5 Doctor on the list. In addition to two of the authors of this book, HTML5 Doctor plays host to a number of extremely talented authors including Bruce Lawson and Remy Sharp, the authors of Introducing HTML5 (New Riders).
• http://dev.opera.com: As a founding member of the HTML5 WHATWG, Opera has been at the forefront of promoting standards-based development focusing largely on the promotion of HTML5. It’s no surprise to see Opera promoting standards through the Opera Developer Community. Regular contributors to the community include Patrick Lauke and Chris Mills (the technical reviewer for this book). It’s well worth bookmarking and checking into regularly.