HTML5 is a Work in Progress
The HTML5 standard is not yet final as of this posting but is in working draft status. Major web browsers are playing catch up to the more stable aspects. I would expect to see HTML5 in major adoption by both user agent and browser providers, as well as developers and designers well within a couple of years. It is already having having an impact, and I would expect to see the adoption for mobile sites to take center stage and displace much of the app store momentum in its wake – after all, why maintain and download many apps when a single mobile web site works both online and offline just as well?
HTML 2.0 (1995) 3.0 amd 3.2 (1997) were quite hodge podge. The 1998 Web Standards Project added weight to the need to let W3C define standards and it pushed for browser developers to follow such standards to help alleviate proprietary tags, behavior, etc that has historically caused many web developer a lot of sleepless nights. HTML 4,0 (1999) has been the standard until even now in many regards. The first true XML based standard (as opposed to almost XML) was XHTML 1.0 (2000) together with its related DTD however most browsers anyway continue to internally render the strict XML markup as if it were still the sloppy HTML version, replete with proprietary behavior quirks (can anyone say Microsoft?). Meanwhile, the increasing expectations for gee-wizz browser functionality brought about by slick high bandwidth connected devices have already placed such serious demands upon developers and architecture that more standardization and functionality was obviously needed. Next up, XHTML2.0 was a work in progress at W3C from early 2000s until 2009 when it was abandoned without any major browser implementations. The point of XHTML 2.0 was to move browsers and developers to a completely XML structured framework however the project was abandoned largely to give way to the WHATWG group (Web Hypertext Application Technology Working Group) founded by experienced developers and designers and adopted into W3C as a formal project in 2007. This project was later renamed to HTML5 and garnered great support among power players in the industry such as Google and Apple. The goal of the HTML5 project is standards to allow designers and developers to more easily create much richer mobile and static web experiences that are compatible across platforms. All this while HTML5 compliance must include that browsers (user agents) remain backwards compatible with earlier non HTML5 markup. HTML5 is an evolution of HTML4, XHTML 1.0 and DOM Level 2.
But Wait a Minute is HTML5 and XML document?
Aha! No it isn’t, however lest you worry about the inherent sloppiness that may be encouraged let me introduce the strictly XML flavor called, you guessed it, XHTML5 which must be served with an XML MIME type. XHTML5 still requires the HTML5 doctype as well as XML’s strict, well-formed syntax.
What’s New in HTML5?
Included are standardized things that reflect what developers have been doing by much more tedious and non standard means in recent years. Things such as:
- new semantic elements (tags) and attributes
- some new content tags..
- <figure> for visual content such as illustrations
- <video> pretty self evident
- <audio> pretty self evident
- <embed> plug in content like Adobe Flash
- <canvas> drawable backdrop
- new form attributes help with things like form validation and auto fill that may be user agent dependent
- <input type=”email”>
- <input type=”url”>
- <input type=”range”>
- <input type=”number”>
- <input type=”date”>
- <input autofocus>
- <input autocomplete>
- <input placeholder=”placeholder text”>
- <input required>
- some new application related tags
- <meter> scalar measurement within a know range
- <progress> fractional completion
- <time> time encoded data various formats
- <details> disclosure widget such as accordion type container
- <command> user invokable command with graphics
- <menu> define menu structures within applications
- APIs for common developer tasks
- inline editing
- offline application
- history – use browser history
- web protocol
- drag and drop page elements
- 2D canvas drawing
- local data storage
- web workers
- web sockets
- Support for simple means to include audio and video
CSS3 is Not Part of HTML5
Though frequently mentioned in the same sentence CSS3 is its own W3C project. CSS3 has theoretically been around since 2000 but development has been split into modules some of which are progressing slower than others. Most current browsers actually support CSS2.1 well. CSS3 deserves its own article. Vendor specific extensions are available to support various aspects of CSS3.
Tip: www.ecsstender.org offers a helper library for cross browser CSS3
Tip: www.css3generator.com tracks vendor specific CSS code
CSS3 will allow much more control of issues such as typography (using local or remote open source or licensed font libraries).
Tip: see www.paulirish.com/2009/bulletproof-font-face-implementation-syntax to learn about current cross browser techniques for font support
Tip: www.fontsquirrel.com lists license free fonts and font kits which include style sheet snippets to include them and license terms (read).
HTML5 Content Models
Tags can be grouped into the following content usage categories or contexts. Many tags belong to more than one usage context.
- Metadata – tags that sets context of presentation or behavior of the document
- Embedded – tags that import other content into the document
- Interactive – tags that define content used for user interaction
- Heading – tags that define header of a section
- Phrasing – tags that define the text of the document (many elements in this category)
- Flow – tags that define presentation flow of the document (this most elements are in this category)
- Sectioning – tags that define the scope of headings and footers
Where is HTML5 at Now?
Implementation is increasing very rapidly eight now (late 2010).
Several other sites include up to date matrices of support. For example:
In a slightly odd twist Mr Softy is on top of HTML5 developments and promises to deliver upon them in IE9 while at the same time IE8 and lower offer little support for HTML5 when compared against most other browsers.
HTML5 Error Handling
Deprecated Tags and Elements
There are several , most notably <u> but most of the others were very rarely used except for many deprecated <table> attributes.
DOM is now part of HTML5 which implies that HTML5 scripts should work on any platform.
New methods include
This is simply ‘<!DOCTYPE html>’
The presence of this with no prior white space as first line of a file triggers HTML5 standards mode for the browser.
This is simply ‘<meta charset=”utf-8″>’
Dealing with IE8 and Below
IE8 and below don’t even know what many new HTML5 tags are. One way to prevent these browsers from breaking is to conditionally include a script snippet hosted by Google which will dynamically retag the offending pages to keep these older browsers happy.
<!--[if lt IE 9]>
Canvas and Canvas API
Tip: since drawing is very fast it is a good idea to make sure external resources have loaded before using them as source for drawing functions. For example use ‘img.onload’ event to trigger call to drawing routines.
Drag and Drop API
Drag and drop has become a fundamental component of modern interfaces.
Unevenly implemented across browsers at present making actual usage difficult. Based off of Microsoft implementation (been present since IE5) but even IE only partially supports the API. Oh wonderful Microsft! Can drag links, images, etc. Event driven.
Tip: Supports dragging elements from external applications – potentially huge!
Offline Web Applications API
This is perhaps the major reason why ‘app-store’ apps may not have such a mainstream future as the current mania surroudning them might suggest.
Store a version of the application in user agent cache along with data. Offline local updates will be synced with cloud upon going back online.
Note: hosting servers must recognize the manifest mime type:
This API is already widely supported, except in IE8 and below (of course)
Tip: Offline applications currently require user to ‘opt-in’ for syncing externally
Current HTML5 spec does not define a standard CODEC and licensing, patent issues are playing out big time currently so that major browsers are targeting differing CODECs. Perhaps the open source and very good VP8 CODEC from Google and others will win out. You can read about this at the WebM Open Media Project Blog. Bottom line it is currently necessary to support at least several CODECs.
Tip:www.videojs.com, and www.html5video.com libraries offer help with this currently messy area.
Example code to public video with CODED fallback in HTML5:
<video width="240" height="236" controls preload="false">
<source src="video/myvideo.mp4" type=video/mp4"/>
<source src="video/myvideo.ogv" type=video/ogg"/>
Tip: Use fall back content to support multiple video formats in the order they should be tried. Note that the iPhone must see mp4 listed first or it will fail. Fall back to flash can also be supported.
Spec is currently at draft stage. It specifically allows each user agent to decide its own approach to finding location and defines standard methods to access and use that data. Device support is moderately good at present time. Location can be found on one shot basis or continuous tracking basis. Currently, the user agent must include methods to ensure the user has to opt in before enabling exposing their location to the application.
Tip: currently, a good cross browser solution is to use Geo.js library. This is hosted at Google.
Adds a this leg to persistence of data. Existing methods include cookies (limited storage), or database or file storage on server. The web storage API is no longer part of the HTML5 working group or spec but has been put in its own sub project: dev.w3.org/html5/webstorage
The web storage mechanism uses key-value pairs to store both ‘session data’ (single session in single window) and for ‘local storage’ (over multiple windows and persists longer than one session). Web storage allows much more data to typically be stored locally when compared to the cookie approach. A set of access methids and event listeners are defined for access and usage of web storage. Support is good cross browser but inconsistent between browsers.
Tip: currently, a good cross browser solution is to use the jStorage plugin (for Prototypejs, Mootools, jQuery etc libraries) found at www.jstorage.info
Note: There are competing approaches to local storage. These include Google Gears and Web SQL Database (another sub project of HTML5)
The web storage API has its own sub project: dev.w3.org/html5/websockets
Prior to AJAX the almost universal approach to client server communications was stateless connections. The client would establish a connection sufficient for a page to be downloaded, then the connection would be closed.
In all cases the client has been required to initiate a connection making it impossible to have the server push content asynchronously to the client without some form of polling by the client. These techniques are obviously wasteful and require complex control of firewalls and proxy servers.
“COMET” is a pre HTML5 Web Sockets work around approach increasingly adopted of late to overcome the lack of a “push” mode from server – such as would be afforded by a persistent connection. This type of functionality is very useful in applications such as monitoring, data logging, updates orchestrated by a cloud based server – the “smart grid” is a typical application where intermittent server initiated communication becomes useful.
The Web Socket is a persistent bi direction client server connection using either the Web Socket or Secure Web Socket communications protocol. As such it circumvents firewall and proxy server issues. It is easy to initiate by client side script and will allow applications such as streaming, push from client, etc.
Tip: This is a big deal, a game changer enabling many new areas of web applications.
Web sockets are not fully supported yet in most browsers.
Tip: check out www.jwebsocket.org