Google Gears is reportedly being relegated to the bench by the Campus (Google, that is, as mentioned in a range of comments before) in order to allow the fun-filled featues of HTML5 to replace the functionality required. Makes sense – why have a fully fledged custom system when a specification exists that covers most of the features that Google Gears encompasses. Also, this makes sense with the editors for the HTML5 spec (of at least the API vocabulary for HTML5) being Ian Hickson from Google, Inc. and David Hyatt of Apple, Inc. fame. (BTW – there’s a good presentation on the features from GoogleIO: GoogleIO presentation on Gears vs HTML5)But what are these HTML5 features? After the hype around FireFox 3.5 and upwards supporting native video in HTML5 (in .ogg format and other), and after YouTube and Vimeo both announced their intention to allow for HTML5 video support (or at least their intention to explore the options), HTML5 went rather quiet in the mainstream.

HTML5 professes to have a variety of page-layout and -structure as well as functional, programming improvements through an API interface. Although IBM Developerworks have a good run-down, a summary follows:

The spedification show these to be the major improvements:

• The use of the DOM as a basis for defining the language.
• The concept of browsing contexts.
• The distinction between user agent requirements and authoring requirements.
• The use of imperative definitions rather than abstract definitions with the requirement of black-box equivalence in implementations.
• The new content model concepts (replacing HTML4’s block and inline concepts).
• The focus on accessibility as a built-in concept for new features (such as the hidden attribute, the progress element, et cetera) instead of an add-on (like the alt attribute).
• The focus on defining the semantics in detail (e.g. the outline algorithm, replacing the vague semantics in HTML4).
• The menu and command elements.
• The origin concept.
• Offline Web application caches.
• The definition of the browsing context “navigation” algorithm and the related session history traversal algorithms.
• The content-type sniffing and character encoding sniffing.
• The very explicit definition of a parser.
• The contentEditable feature and the UndoManager feature.
• The Drag and Drop and Copy and Paste architecture.
• The new sandboxing features for iframe.

So as opposed to HTML4, from a non-API side the improvements can be summed up as below:

• New parsing rules oriented towards flexible parsing and compatibility; not based on SGML
• Ability to use inline SVG and MathML in text/html
• New elements – article, aside, audio, canvas, footer, hgroup, meter, nav, progress, section, time, video
• New types of form controls – dates and times, email, url, search
• New attributes – ping (on a and area), charset (on meta), async (on script)
• Global attributes (that can be applied for every element) – id, tabindex, hidden, data-* (custom data attributes)
• Forms will get support for PUT and DELETE methods too instead of just GET and POST
• Deprecated elements dropped – center, font, frameset, strike

The API side presents the following:

• The canvas element for immediate mode 2D drawing
• Timed media playback
• Offline storage database
• Document editing
• Drag-and-drop
• Cross-document messaging
• Browser history management

Now it’s just a matter of finalising the spec – which can be tricky. Dates from 2012 as Candidate Spec to 2022 as Recommendation Spec have been waved about. However, a variety of elements can already be coded into the web as long as the web browser fraternity embraces and supports them.