Basics: What is HTML5? - JUMP START HTML5 (2014)

JUMP START HTML5 (2014)

Chapter 1 Basics: What is HTML5?

The easy answer is that it’s the latest version of HTML. But that doesn’t tell us much. Specifically, HTML5:

· defines a parsing algorithm for generating a consistent DOM (Document Object Model) tree, even from ambiguous or poor-quality markup

· adds new elements to support multimedia and web applications

· redefines the rules and semantics of existing HTML elements

With HTML5, we can now embed audio and video natively within HTML documents. We can use inline SVG (Scalable Vector Graphics) markup. We can build more robust form experiences, complete with native error checking. We can create games, charts, and animations using thecanvas element. Documents can communicate with each other using cross-document messaging. In other words, HTML5 is much more of an application platform, not just a markup language.

A Brief History of HTML5

The story of how and why HTML5 came to be is too long to adequately cover in this book. That said, a little historical context may help you understand some of how HTML5 came to be.

HTML has its roots in Standard General Markup Language, or SGML. Think of SGML as a set of rules for defining and creating markup languages.

HTML, or HyperText Markup Language, began as an application of SGML. Created in the early 1990s, HTML was a standardized way to describe the structure of hypertext documents. "Hypertext" simply means that the text "contains links to other texts" and is not constrained by linearity.

By describing the structure of a document, we decouple it from how it looks, or how it’s presented to the end user. This made it easier to share and redistribute. The associated Hypertext Transfer Protocol (HTTP) made sharing documents over the internet easy.

HTML: The Early Years

"HTML 1" defined a simple, tag-based syntax for explaining document structure—a very basic document structure. Paragraph (p) and list item (li) elements didn’t require an end tag. The earliest version didn’t even include the img or table elements. Image support was added in version 1.2of the specification.

HTML grammar changed only slightly with version 2.0. Now we could use end tags for elements such as p and li, but these end tags were optional. The transition from HTML 2.0 to HTML 3.2, however, marked a huge leap.

With HTML 3.2, we could change type rendering with the font element. We could add robust interactivity with Java applets and the applet element. We could add tabular data with the table, tr and td elements. But perhaps the most significant feature introduced in HTML 3.2 was style sheets.

Most of the web, however, settled on HTML 4. With the advent of HTML 4, we could tell the browser how to parse our document by choosing a document type. HTML 4 offered three options:

· Transitional, which allowed for a mix of deprecated HTML 3.2 elements and HTML 4

· Strict, which only allowed HTML 4 elements

· Frameset, which allowed multiple documents to be embedded in one using the frame element

What HTML versions 1 through 4 didn’t provide, however, were clear rules about how to parse HTML.

The W3C stopped working on HTML 4 in 1998, instead choosing to focus its efforts on a replacement: XHTML.

A Detour Through XHTML Land

XHTML 1.0 was created as "a reformulation of HTML 4 as an XML 1.0 application." XML, eXtensible Markup Language, was a web-friendly revision of SGML, offering stricter rules for writing and parsing markup.

XHTML, for example, required lower case tags while HTML allowed upper case tags, lower case tags, or a mix of the two. XHTML required end tags for all non-empty elements such as p and li. Empty elements such as br and img had to be closed with a />. You had to quote all of your attributes, and escape your ampersands. All pages had to be served as application/xml+xhtml MIME type.

XHTML taught us how to write better-quality markup. But ultimately suffered from a lack of proper browser support.

XForms, on the other hand, was supposed to replace HTML forms. XForms introduced upload and range elements to provide richer ways to interact with web sites.

XForms didn’t gain much traction, however. After all, why introduce a specific markup language for forms to the web? Why not enhance HTML instead?

The Battle for World DOM-ination

In 1996, Netscape released Netscape Navigator 2.0 with support for two separate, but related technologies: JavaScript and the Document Object Model. We usually talk about them as though they’re one and the same thing, but DOM is an API for interacting with HTML documents. JavaScript is the primary language for interacting with that API.

Netscape Navigator’s DOM interface turned each element of an HTML page into an object that could be created, moved, modified, or deleted using a scripting language. Now we could add animation or interactivity to our web pages, even if we had to wait ages for them to download over our super-slow, 14.4Kbps modems.

The DOM was such a brilliant addition to the web that other browsers quickly followed suit. But not every browser implemented the DOM in quite the same way. Netscape Navigator, for example, used document.layers objects to reference the entire collection of HTML nodes. Microsoft Internet Explorer went with document.all. And web developers everywhere spent years struggling to reconcile the two. Opera and WebKit, for what it’s worth, followed Internet Explorer’s lead. Both browsers adopted document.all.

Eventually "DOM0" went from being a standard-through-implementation to a standard-through-specification with the Document Object Model (DOM) Level 1 Specification. Rather than document.layers and document.all, we could use document.getElementById anddocument.getElementsByTagName. Today, all browsers support the DOM.

Applets and Plugins

In the midst of all of this—the growth of HTML, the rise of the DOM, and the shift to XHTML—applets and browser plugins joined the party. To their credit, applets and plugins added functionality missing from HTML. For example, RealPlayer and Apple’s QuickTime brought audio and video to the web. With Java applets, you could run a spreadsheet program in your browser. Macromedia (now Adobe) Flash and Shockwave let us add all of the above, plus animations.

Applets and plugins, however, suffered from three major problems:

1. Users who don’t have the plugin (or the applet environment) can’t see the content.

2. Applets and plugins expanded the surface for internet-based security breaches.

3. They were commercial products, and required developers to pay a license fee.

What’s more, plugins and applets sometimes caused their host environment—the browser—to slow or crash.

So what we had on the web was a scenario in which:

· Browsers didn’t parse HTML according to the same rules.

· New markup languages offered few clear advantages over HTML but added overhead to implement.

· Plugins and applets offered additional functionality, but created security and stability issues for browsers and licensing costs for developers.

These are the problems that HTML5 solves:

· It incorporates features and grammars introduced by XHTML and XForms.

· It almost eliminates the need for plugins and the stability and security issues they may introduce.

What HTML5 Isn’t

I admit that I’m taking a bit of a purist approach in this book. HTML5 has become a buzzword-y shorthand for "everything cool we can do in the browser that we couldn’t do before." In this book, however, we mean HTML elements and their Document Object Model (DOM) APIs.

We won’t talk much about features introduced with CSS (Cascading Style Sheets), Level 3 in these pages. We will talk about what’s commonly called "JavaScript", but is more accurately the DOM HTML API. We’ll also talk about Scalable Vector Graphics, or SVG—but only to the extent that we discuss mixing SVG and HTML within the same document.

This book is intended as a short introduction to HTML5. For that reason, we won’t cover advanced features in depth. This book will, however, give you an introduction to what’s new and different about HTML5 versus previous versions.

A Note on the HTML5 Specification

Both the Web Hypertext Application Technology Working Group (WHATWG) and the World Wide Web Consortium (W3C) publish HTML5 specifications. The two groups worked together for years, creating a single specification managed by a single editor. However in 2011, they diverged. There are now two competing, though largely similar, versions of the specification. Each has its own editor.

The WHATWG version of the specification is a "living document." New features are added, tweaked, and occasionally removed after some discussion within the community. This version is far more fluid and subject to change.

The W3C, however, has a different process. Specification editors still consult the community, but each document moves in phases from "Working Draft" to "Candidate Recommendation" to "W3C Recommendation." As a result, W3C specifications are versioned. The 2011 joint version of HTML5 specification became the W3C’s HTML5 Specification. Subsequent revisions are part of the HTML 5.1 specification.

There are differences between the two specifications, some subtle, some significant. These differences are not well documented, however. Since this book doesn’t delve in to the minutiae of HTML5, these differences won’t mean much for us.