D. From HTML+ to HTML5

D

From HTML+ to HTML5

I’m not sure any HTML specification has had such fanfare as HTML5. It offers so many promising possibilities, in fact, that it has become something of a buzzword with connotations far beyond the spec itself. When marketers and journalists use the term “HTML5,” they are sometimes referring to any new web technology that replaces Flash. Throughout this book, you have gotten familiar with the elements of HTML5, and in this appendix, I’ll tell you a bit more about the spec itself, so you can join those of us who are irked when we hear “HTML5” used incorrectly. The important thing, however, is that mainstream awareness of web standards is certainly a win and makes our job easier when we’re communicating with clients.

But first, I think it’s important to know how we got here and what makes HTML5 a breakthrough. I’ll start with a brief history of HTML, and then point out some unique qualities of HTML5, including its APIs.

An Abbreviated History of HTML

Understanding where we’ve been provides useful context for where we are going. Our journey to HTML5 passes through the frontier of the early web, the dangerous battlegrounds of the Browser Wars, and a flirtatious fling with XML.

The Wild Frontier

The story of HTML, from Tim Berners-Lee’s initial draft in 1991 to the HTML5 standard in development today, is both fascinating and tumultuous. Early versions of HTML (HTML+ in 1994 and HTML 2.0 in 1995) built on Tim’s early work with the intent of making it a viable publishing option.

But when the World Wide Web (as it was adorably called back in the day) took the world by storm, browser creators, most notably Mosaic Netscape and later Microsoft Internet Explorer, each said, “We ain’t waitin’ for no stinkin’ standards!” They gave the people what they wanted by creating a slew of browser-specific elements for improving the look of pages on their respective browsers. This divisive one-upping is what has come to be known as the Browser Wars. As a result, it became common in the late 1990s to create two entirely separate versions of a site that targeted each of the Big Two browsers. Signs on sites reading “Best viewed in Netscape” were the norm. I shudder just thinking about it.

A Call for Reason

In 1996, the newly formed W3C put a stake in the ground and released its first Recommendation: HTML 3.2. It is a snapshot of all the HTML elements in common use at the time, and includes many presentational extensions to HTML (such as the font and center elements) that were the result of the Netscape/IE feud and the lack of a style sheet alternative. HTML 4.0 (1998) and HTML 4.01 (the slight revision that superseded it in 1999) aimed to get HTML back on track by emphasizing the separation of structure and presentation and improving accessibility. All matters of presentation were handed over to the newly minted Cascading Style Sheets standard that was gaining support.

HTML 4.01—along with XHTML 1.0, its stricter XML-based sibling (discussed next)—became the cornerstone of the web standards movement (see the sidebar “The Web Standards Project”).

Enter XML and XHTML

Around the same time that HTML 4.01 was in development, folks at the W3C became aware that one limited markup language wasn’t going to cut it for describing all the sorts of information (chemical notation, mathematical equations, multimedia presentations, financial information, and so on) that might be shared over the web. Their solution: XML (eXtensible Markup Language), a metalanguage for creating markup languages. XML was a simplification of SGML (Standardized Generalized Markup Language), the big kahuna of metalanguages that Tim Berners-Lee used to create his original HTML application. But SGML itself proved to be more complex than the web required.

The W3C had a vision of an XML-based web with many specialized markup languages working together—even within a single document. Of course, to pull that off, everyone would have to mark up documents very carefully, strictly abiding by XML syntax, to rule out potential confusion.

Their first step was to rewrite HTML according to the rules of XML so that it could play well with others. The result is XHTML (eXtensible HTML). The first version, XHTML 1.0, is nearly identical to HTML 4.01, sharing the same elements and attributes, but with stricter syntax requirements (see the “XHTML Markup Requirements” sidebar).

But the W3C didn’t stop there. With a vision of an XML-based web in mind, they began work on XHTML 2.0, an even bolder attempt to make things work “right” than HTML 4.01 had been. The problem was that it was not backward-compatible with old standards and browser behavior. The writing and approval process dragged on for years with no browser implementation. Without browser implementation, XHTML 2.0 was stuck.

Hello HTML5!

Meanwhile…

In 2004, members of Apple, Mozilla, and Opera formed the Web Hypertext Application Technology Working Group (WHATWG, whatwg.org), separate from the W3C. The goal of the WHATWG was to further the development of HTML to meet new demands in a way that was consistent with real-world authoring practices and browser behavior (in contrast to the start-from-scratch ideal that XHTML 2.0 described). Their initial documents, Web Applications 1.0 and Web Forms 1.0, were rolled together into HTML5. Today, the WHATWG maintains an unnumbered, “living” HTML standard.

The W3C eventually established its own HTML5 Working Group based on the work done by the WHATWG. HTML5 reached formal Recommendation status in October 2014. As of early 2018, the latest version is HTML 5.2, which is a “Proposed Recommendation.”

Work on the HTML5 specification is happening in both organizations in tandem, sometimes with slight inconsistencies. For the most part, browser vendors use the WHATWG copy as their implementation reference.

And XHTML 2.0? At the end of 2009, the W3C officially put it out of its misery, pulling the plug on the Working Group and putting its resources and efforts into HTML5.

So that’s how we got here. Now let’s get to know HTML5 a little better.

HTML5: More Than Markup

Prior HTML versions concerned themselves mainly with elements for marking up content to be viewed on web pages. HTML5 is a bundle of new methods for accomplishing tasks that previously required special programming or proprietary plug-in technology such as Flash or Silverlight. Solutions include both markup and scripting components, including APIs for things like putting audio and video on the page, storing data locally, working offline, taking advantage of location information, and more. With HTML5 for common tasks, developers can rely on built-in browser capabilities and not reinvent the wheel for every application.

Much of what’s new in HTML5 requires advanced web development skills, so it’s unlikely you’ll use those features right away (if ever), but as always, I think it is beneficial to everyone to have a basic familiarity with what can be done. And “basic familiarity” is what I’m aiming at here. For more in-depth discussions of HTML5 features, see the “Further Reading” sidebar.

HTML5 Markup Component

You’ve been learning the elements and attributes of HTML5 throughout this book.

HTML5 is based on HTML 4.01 Strict, the version of HTML that did not include any presentation-based or other deprecated elements and attributes. That means the vast majority of HTML5 is made up of the same elements that were used for years, and browsers know what to do with them.

HTML5 introduced a number of new elements, form input types, and global attributes. It also made many deprecated elements and attributes in HTML 4.01 officially obsolete.

One departure from previous HTML versions is that HTML5 is the first specification that includes detailed instructions for how browsers should handle malformed and legacy markup. It bases the instructions on legacy browser behavior, but for once, there is a standard protocol for browser makers to follow when browsers encounter incorrect or non-standard markup.

A DTD-Free DOCTYPE

As we saw in Chapter 4, Creating a Simple Page, HTML documents should begin with a Document Type (DOCTYPE) declaration that identifies which version of HTML the document follows. The HTML5 declaration is short and sweet:

<!DOCTYPE html>

Compare that to a declaration for a Strict HTML 4.01 document:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/HTML4.01/strict.dtd">

Why so complicated? For documents written in HTML 4.01 and XHTML 1.0 and 1.1, the declaration must point to the public DTD (Document Type Definition), a document that defines all of the elements in a markup language as well as the rules for using them. DTDs are a remnant of SGML and proved to be less helpful on the web than originally thought, so the authors of HTML5 simply didn’t use one. As a result, the DOCTYPE declaration is much simpler.

Validators—software that checks that all the markup in a document is correct (see Note)—use the DOCTYPE declaration to make sure the document abides by the rules of the specification it claims to follow.

Both HTML 4.01 and XHTML 1.0 had three separate DTDs (for Traditional, Strict, and Frameset versions of each spec), so there were a lot of little details to keep track of. For a full list of DOCTYPE declarations (including DTD references) for HTML 4.01, XHTML, SVG, and other document types, go to www.w3.org/QA/2002/04/valid-dtd-list.html.

Meet the APIs

HTML specifications prior to HTML5 included only documentation of the elements, attributes, and values permitted in the language. That’s fine for simple text documents, but the creators of HTML5 had their minds set on making it easier to create web-based applications that require scripting and programming. For that reason, HTML5 also defines a number of new APIs for making it easier to communicate with an application.

An API (application programming interface) is a documented set of commands, data names, and so on, that lets one software application communicate with another. For example, the developers of Twitter documented the names of each data type (users, tweets, timestamps, etc.) and the methods for accessing them in an API document (dev.twitter.com/docs) that lets other developers include Twitter feeds and elements in their programs. That is why there are so many Twitter programs and widgets available. Amazon.com also opens up its product data via an API. In fact, publishers of every ilk are recognizing the power of having their content available via an API.

But let’s bring it back to HTML5, which includes APIs for tasks that traditionally required proprietary plug-ins (like Flash) or custom programming. The idea is that if browsers offer those features natively—with standardized sets of hooks for accessing them—developers can do all sorts of nifty things and count on them working in all browsers, just as we count on the ability to embed an image on a page today. Of course, we have a way to go before there is ubiquitous support of these cutting-edge features, but we’re getting there steadily. Some APIs have a markup component, such as embedding multimedia with the new HTML5 video and audio elements. Others happen entirely behind the scenes with JavaScript or server-side components, such as creating web applications that work even when there is no internet connection (Offline Web Application API).

The W3C and WHATWG are working on lots and lots of APIs for use with web applications, all in varying stages of completion and implementation. Most have their own specifications, separate from the HTML5 spec itself, but they are generally included under the wide HTML5 umbrella that covers web-based applications. HTML5 includes specifications for these APIs:

Media Player API

For controlling audio and video players embedded on a web page, used with the new video and audio elements.

Editing API

Provides a set of commands that could be used to create in-browser text editors, allowing users to insert and delete text; format text as bold, italic, or hypertext; and more. In addition, there is a new contenteditable attribute that allows any content element to be editable right on the page.

Session History API

Exposes the browser history for better control over the Back button.

Drag and Drop API

Adds the ability to drag a text selection or file to a target area on the page or another web page. The draggable attribute indicates the element can be selected and dragged.

The following are just a handful of the APIs in development at the W3C with specifications of their own:

Canvas API

The canvas element adds a dynamic, two-dimensional drawing space to a page. The canvas element is discussed in Chapter 10, Embedded Media.

Service Workers API

This specification describes a method that enables web applications to work while offline.

Web Storage API

Allows data to be stored in the browser’s cache so that an application can use it later. Traditionally, that has been done with “cookies,” but the Web Storage API allows more data to be stored. It also controls whether the data is limited to one session (sessionStorage: when the window is closed, the data is cleared) or based on domain (localStorage: all open windows pointed to that domain have access to the data).

Geolocation API

Lets users share their geographical location (longitude and latitude) so that it is accessible to scripts in a web application. This allows the app to provide location-aware features such as suggesting a nearby restaurant or finding other users in your area.

Web Sockets API

Creates a socket, which is an open connection between the browser client and the server. This allows information to flow between the client and the server in real time, with no lags for the traditional HTTP requests. You can think of a web socket as an ongoing telephone call between the browser and server compared to the walkie-talkie, one-at-a-time style of traditional browser/server communication. (A hat tip to Jen Simmons for this analogy.) It is useful for multiplayer games, chat, or data streams that update constantly, such as sports or stock tickers or social media streams.

Where We Go From Here

With a system in place that seems to be working, all indications are that the HTML specification will continue to undergo minor revisions in order to keep up with the changing demands of how we use the web and the devices we use it on. Minor revisions generally include adding attributes, elements, and APIs and putting to rest features that were never implemented. In other words, I have not heard talk of another seismic shift such as the switch from XHTML to HTML5.

At the W3C, HTML 5.2 (the 5th major version and second minor revision of HTML) became a Recommendation on December 14, 2017. As this book goes to press, there is already a Working Draft of HTML 5.3. Meanwhile, the WHATWG maintains its “living” (unnumbered) version of HTML that is continually updated and forms the basis for most browser vendors’ implementation.

So know that HTML is always changing, and as a web designer or developer, you will need to keep your ear to the ground. There is always something new to learn.