HTML5: An Introduction [DRAFT]

Rochelle Mazar, rochelle.mazar@utoronto.ca

Emerging Technologies Librarian

University of Toronto Mississauga

Introduction

The history of HTML is long, fascinating and complicated. No one body created and diseminated HTML; it is a collaboration on a grand scale, forged on listservs and private email, created by both arbitrary and considered opinion of authors, browser company employees, and any interested parties. It is perhaps the first and best example of how the internet can foster collaborative growth and change.^[1]

Web browsers are extremely forgiving. It’s estimated that 99% of webpages have HTML errors written into them^[2], but because the errors don’t display and no content is missing, no one is compelled to fix them. With formal standards appearing only after demonstrated use, web content has been created and code written based on what common web browsers would reliably display; current browsers are essentially required to break the established standards in the same way their predesessors did in order to display pages the way users expect them to.

HTML5 was born because W3C, the web standards body, wanted to drop HTML in favour of XML (and the hybrid XHTML)^[3]. Unhappy with this decision, the Web Hypertext Applications Technology (WHAT) Working Group^[4], made up of members from Google, Apple, Opera and Mozilla, among other interested parties, was formed to lead the development of the next iteration of HTML: HTML5.

To understand why these ongoing changes to HTML are so important, we should trace back the history of what a webpage is. In the beginning, there was always a file on a server that contains the whole of a webpage’s content; the style elements were added to the content itself as markup. You could download the file and have the whole of the page in front of you. These files were contained within folders, much like a folder structure on your desktop.

We quickly developed a metaphor of “document” to describe what was happening with the web: our browser knocks on the door of the web server and gets a single answer. After that, the connection is closed, communication complete. A single interaction like this (a question: “what’s there?” an answer: “This is!”) is best understood as document retrieval. Documents, digital and in paper, are kept organized in folders. It’s a neat, simple way to view our interaction with the web.^[5]

With the introduction of dynamic websites, this model started to change a little. The style and the content separated, and the content no longer resided within a single file. Pages can dynamically draw content out of a database based on any number of variables. That means any given page is like Schrödinger's cat: the reality of it is formed the moment you load the page. Before you display it, the content of a dynamic webpage exists in any number of different locations, separated into individual bits that can be rearranged at will. A webpage file, then, becomes only a template, with key content elements dictated by internal (hard coded) or external (user-generated) referents. While a website might seem like thousands of distinct pages, it could in fact be a single template page with highly variable, user-directed content. But it’s still a document, a single bit of communication after which the door closes, and the doorman really only has this one bit to say.

Remember that at the beginning, HTTP was only one of many protocols available to internet users. The World Wide Web was only one piece of the mosaic that was the internet experience circa 1991, and it was by far the least interactive. A web document opens the door to the server just once, creating a single static retrieval: FTP, IRC, and Telnet, among others, opened up a door on a server that stayed open. Rather than a document, these instances were more like virtual worlds, communication platforms, or games; they responded to user input, and allowed users to interact with the content and with each other. Since the World Wide Web has become the standard mode for internet usage, programmers have been devising ways to break free from that single moment of information exchange between the browser and the webserver, to bring together the graphical beauty of the web with the fast, easy interaction of Telnet or IRC.

In order to approach this, web browsers are currently dependent on a host of third-party plugins and media embeds,like Java applets, Flash, Real, Silverlight, Adobe Air, and others. These additions allow a standing web page to interact continuously with the server; it jams a foot into the door and wedges it open, if only in a limited fashion.

Starting in 2000 with Outlook Web Access, and getting wide release in 2004 when Google incorporated it into Gmail, Ajax was a game-changer. Ajax is a combination of HTML, CSS, JavaScript, and XML which allows a website to check in with the web server repeatedly, without being locked into a flash box and without browser plugins. Ajax is what powers Google Maps, Google Docs (with its new multi-cursor synchronous collaboration), Meebo, and Facebook. Ajax is what lets you see new mail appear in your gmail inbox without refreshing your browser window, and allows you to have a conversation with a friend in Google Talk. Ajax’s model of web interaction is what HTML5 hopes to make standard, forever altering our notion that the web is a series of documents. The web is about to become a series of interactive places.

What is HTML5?

Rather than use third party software, the latest iteration of HTML5 will incorporate their functionality, allowing any user, even one without any plugins at all, to see rich content, interact directly with the content without refreshing their screens, and take advantage of features like geolocation.

HTML5 isn’t an independent monolithic structure; it’s a series of functions and standards that can be implemented piecemeal by browsers (and in fact are already being implemented in the latest versions of Safari, Firefox, and Opera browsers, both for traditional computers and smart phones).  It is a standard that allows a basic browser to become a lot more interactive without the user having to update endless plugins.

Canvas and Text Canvas

The canvas element of HTML5 allows you to create highly interactive tools and animations, much like Flash games.  The latest version of Adobe Creative Suite (Flash authoring tools) includes the ability to export animations to HTML5 Canvas.

Examples

• CanvasPaint
• Harmony
• Liquid Particles
• Canvas in 3D
• GoogleBox

Resources

• Mozilla Canvas Tutorial
• How to Draw with HTML5 Canvas
• Creating an HTML5 Canvas Painting Application

Video

Rather than depend on a third party plugin like Flash, RealPlayer or Quicktime, HTML5 contains a <video> tag that will allow you to simply point to a video and have it play in your webpage. This means that iphone users will have equally good access to video content as computer users, and a user who has no plugins at all, and cannot download any, will still have access to video and audio content. With the <video> tag, you can embed video as easily as you embed images in a webpage.

Examples

• Video Canvas

Editable Content

We’re used to the idea that wikis allow us to edit content on websites without going into some kind of back end product; the editable content functionality of HTML5 allows you to specify any part of your page as editable. That edit might be stored only on the user’s computer, allowing any user to edit content on a page that only they will see.

Examples

• ContentEditable

Drag and Drop

We have become accustomed to our desktop applications allowing us to drag and drop content as a means of interaction; Flash also allows users to drag and drop content or tools. HTML5 allows for the same kind of functionality in a web page without plugins.

Examples

• Drag and Drop
• Permissions

Local Storage

HTML5 contains functionality much like cookies, but with much greater storage capacity. Local Storage allows a website to store your personal preferences and other information on your computer, so that they next time you visit the site, your preferences are still there. This local storage is locked so that while many sites can store data on your computer, each site can only access data it stored. This means a website can trigger a memory on a user’s computer for just about anything: searches attempted, documents downloaded, reading lists, etc. Your website can help a user find key content on their own hardrive.

Web Workers

Because JavaScript has become a crucially important language that allows a web browser to act more as a fully-functioning client and not just a web viewer, HTML5 contains some functionality to allow JavaScripts to run well in the background without interrupting the user’s experience. Websites can then employ these Web Workers to do complex functions behind the scenes, letting the users’ computer do some of the work to make the web experience faster and without any lags or interrupted scrolling/clicking.

Offline Web Applications

If your website isn’t a document, but is an application, like Google Docs, you’ll want to be able to visit it at any time to get that functionality. With Offline Web Applications, a site can configure itself to download key files so that when a user visits the application when offline, it will still function. The browser senses that there is no internet connection and replaces key files with the offline ones stored on the computer. The user can they create content and save it, and the next time the user visits the site while online from that computer, all the new content is automatically uploaded to the web application, seamlessly adjusting to periods of offline use.

Geolocation

Devices of all kinds are already location aware: your location is embedded in your connection (either cellular tower, IP address, network router, etc) even if you’re not employing a GPS device. Increasingly, applications and sites are tapping into that information to deliver content or increase interactivity. This means a website can display your location in a map, and help orient you.

Examples

• Geolocation