Summary

Over the past year there has been a growing momentum and excitement for the early implementation and adoption of the next generation of HTML - HTML5. It has been touted as many things; but the fact remains that it’s still very much a work in progress (WIP).

The W3C is a World Wide Web (W3) Consortium. Directed by Tim Berners-Lee - accredited by most (although, on occasion, acrimoniously by others, claiming that DARPA in the US composed the original internet in a research project known as ARPANET in the early 60’s), is accredited as the original “inventor” of the “internet” as we know it today. The W3C is truly a global Consortium chaired by leaders and visionaries of technology from all industries. Apache, Apple, Microsoft, IBM, Facebook, Google and Oracle representatives are just a few examples of companies who sit on the W3C board. Beijing University of Technology is also a current member. The W3C is both broad and encompassing.

The W3C is responsible for defining global standards for use in Internet Technologies. Everything from protocol topology and email network transportation to web-markup, including, recently, defining HTML5.

HTML5 is still officially only a draft version though with the final version not due, reportedly, until sometime in 2022.

2022? But HTML5 is being used now? This is true; a lot of the top browser developers (Google, Opera, Firefox, Internet Explorer and Safari) have started to include some specifications of HTML5 into their browsers. NOTE: They also sit on the board of the W3C. HTML5 specifications that appear to have the most adoption will undoubtedly make it into the final draft because those same browser companies also sit on the board of the W3C and have a vested interest in seeing some technologies and standards included in the final release of HTML5. What this means though is that a generation of web-developers are being exposed to some of the early benefits and advantages of HTML5 and CSS3.

However, because these specifications are still in draft a lot of the finer details are being hashed out as they are being standardized by the W3C. Here are some considerations and introductions to some of the advanced capabilities that HTML5 will offer.

<video /> and <audio />

Undoubtedly the biggest motivator behind HTML5 is the need for browsers to no longer rely on third-party plug-ins to run disparate technology API’s that are used to drive common mediums (namely Video and Audio). Adobe Reader, Flash Player and Silverlite are just a few existing plug-ins that allow these third-party technologies to run in a browser. HTML5 will largely remove the need for some “plug-ins” by including those technologies natively into the browser and the HTML5 specification. Video and Audio are two tags that are included in HTML5 that will do just that. However. There are some considerations.

In order to play video content in a browser you need what’s called a “codec”. Codec’s are licensed, proprietary technologies of their respective owners. MPEG4/H.264  is currently the most popular codec for web. It’s also the proprietary technology of Apple. To use it you have to license it. Internet Explorer and Chrome have “licensed” this technology for use in their browsers. Unfortunately Mozilla Firefox and Opera haven’t. They have had to adopt an “open-source” codec called Theora (OGG). This instantly creates a problem for any HTML5 developer wishing to make full use of a video element in anything other than a Mobile environment. To ensure a user will be able to view a video in ALL browsers; two formats must be available to the browser. An OGG format and an MPEG format. This brings us right back almost two decades to when separate WMV files had to be made for Windows users and MOV files had to be made for MAC users.

Google, however, have recognized this small problem and created a universal, open source codec called VP8.

However you can begin to understand some of the current limitations of the video element. Those same limitations are applied to the audio tag and audio codec’s. Current video codec support :

Update: October 5th, 2012 - More information on Supported Formats.

Fonts

One of the most impressive benefits of CSS3, the next generation of Cascading StyleSheet syntax to accompany the HTML5 standard, is the ability to use ANY font on the web and create some very intricate animations. Font usage has been something that’s plagued many web-designers for years. Until HTML5, without third-party technology, designers have been limited to a very stale palette of fonts.

The @font declaration allows any developer to host a font on their web-server and render web-copy in that font.

This does raise another concern though. Again; licensing. The potential is now too easy for anyone to copy a licensed font (Adobe for example) from their local fonts folder up-to their web-server and use it to render web content. This has ‘caused some dilemma and an introduced an incredible “grey-area”. In traditional print you have to purchase licenses to use Adobe fonts (typically included in the CS suite), now you are at liberty to distribute these font’s via. the web.

Google, again, has had some for-site and established the Google Web Fonts directory. An “open-source” collaboration of enthusiastic font-designers “show casing” their work for free/donations and allowing a wider internet community to download and use their fonts in web-production license free.

WebGL/SVG and the <canvas /> Tag.

The <canvas /> tag has been touted as the biggest change in internet markup for years. It is a DOM element that will allow developers to literally “paint” into a “canvas” with a variety of vector/3D based languages and technologies. It enables a new depth of interaction and animation previously only seen in third party technologies such as Flash and Silverlite. The biggest proponent of this technology is that it doesn’t require plug-ins.

Already there is a huge amount of “buzz” around this topic with some major internet companies (Facebook) aligning themselves for a “newer-generation” of internet.

The breadth of the canvas tag’s capabilities is truly remarkable. One of the most interesting opportunities presented is WebGL. A Web based Graphics Language (GL). Based on an already established 3D graphics language called OpenGL. WebGL opens a gateway for rendering 3D based objects in real time in a user’s web-browser. Traditional 3D rendering software such as “Maya” can be used to composite 3D wireframes, then imported and rendered by WebGL directly in the browser.

One particular community of developers (games developers) is very interested in WebGL. Traditional games developers already write OpenGL code. WebGL is a simple stepping-stone and will allow them to right games that no longer require DVD’s and software installation; they will run directly in your web-browser from the cloud.

However, again, there are some wider considerations. WebGL, a specification of HTML5, is still very much in draft. Only a limited number of browsers currently support it and SVG (Scaleable Vector Graphics) language.

For examples of what WebGL will offer view these links. You will need to view them in Google Chrome, Firefox 4, or Safari 5 to preview them correctly.

Javascript 3D WebGL Engine Examples.
Google Chrome WebGL Experiments.
Cutting edge WebGL and CSS3

Conclusion.

So what are the benefits of using HTML5 now then if it’s still a draft technology?

Simple answer. Mobile technology. HTML5 is, undoubtedly, here to stay. Key proponents of the HTML5 specification have already seen massive adoption.

The latest Operating Systems on iPhones/iPads, ‘Droids, Windows Phones/Tablets and Blackberries all support a majority of HTML5 specifications. Web developers are currently leveraging HTML5 to offer a richer, more engaging browsing experience on Mobile Devices.

Sadly HTML5 on traditional devices (desktops, laptops) will need to wait until the internet community adopts the latest browser technology. Expressly: Firefox4+ and Internet Explorer 9+.

HTML5 support on SmartPhones/Tablets.

A couple of posts back I mentioned about a current diversification of HTML5 video-codec's as browsers continue to include more and more HTML5 support into their nightly builds based on, what is currently still, a draft version of HTML5. You see, all of these awesome new tags like video, audio and canvas (to some extent) rely on a browser being able to natively support that content. Having that technology proprietorial available.

Prior to HTML5 this was managed with "plug-ins". You had your Quicktime plug-in, your Windows Media Player plug-in; pretty rapidly during HTML4 the plethora of plug-ins quickly expanded. Silverlite, Flash, AIR etc... All just API technologies that allowed the browser to tap into to the power of other software via. API calls built into the plug-in. That's what made plug-ins such a pain though. There were so many technologies with associated plug-ins. Whilst this was fine for very specific, technology-centric applications, for more common content requirements, like say video, it was a pain; and dare I say it, that is where Flash offered a haloed solution. A single format that required a single-plugin that ran on all the major engines. Trident, Gecko, WebKit and Presto etc... That was it's success. Singularity.

That is my dilemma. Now we are back in the 80's to some extent. The whole point of HTML5 is to have unity, ubiquity, a single standard. It's great my browser natively supports HTML5 video; but they don't all share the same codec to play that video.

Webkit based browsers like Safari and Chrome have gone the H.264 route, as has, unbelievably Microsoft with it's Trident engine.
Opera(Presto) and Firefox(Gecko) have both gone with the OGG Theora Codec siting potential licensing and patent issues in the future being the reason for not going the H.264 route.
Google have had some foresight based on potential licensing/patent issues and have now developed their OWN codec. The VP8 Video Codec.

Why am I repeating this. Because this is the problem. For true HTML5 compatibility I now need to encode my video in at least 2 different formats. I'm back to the Quicktime Vs. Windows Media Plugin issue. Then stepped in Flash, and I'm guessing, this is the approach Google are taking with their VP8 Codec in this analogy. They hope to offer that ubiquity Flash did. If I was Adobe I'd be focusing on that right now, ubiquitous video, the HTML5 equivalent of Flash.

Anyway, back to the original title. WebGL. What is it. WebGL is a context of the canvas tag. Through API technology and traditional Javascript you can expose 3D graphics content into the HTML canvas tag and utilize the power of your users graphics hardware. You can initialize powerful renderers and shaders. Experiment with bump mapping and anisotropic filtering (things that game-developers have been doing for years) to display some amazing 3D graphics. This O3D WebGL API is just one amazing example of this. WARNING: You need a WebGL compliant browser and some pretty decent Graphics hardware (ATI/nVidea) to appreciate this at it's best.

But again it's like the video/audio codec. Whilst WebGL is an already defined standard, there are now several "middle-ware" implementations out there.

O3D, GLSL and a ton of other libraries that incorporate WebGL: GLGE, C3DL, Copperlicht, SpiderGL, SceneJS, Processing.js and XB PointStream.

Could this be another HTML5 diversion; each browser deciding to implement different "middle-ware" WebGL API's? Will my Gecko WebGL API code not work on a WebKit based browser?

In either case I can foresee developers that are able to command the full extent of the canvas tag being in demand. The canvas tag is literally that, a canvas onto which you need to paint with other API's. WebGL and SVG are just two examples. I think we could even see game-developers joining web-teams bringing their seasoned experience of WebGL development to the internet. The canvas tag is definitely a deep well. With the potential for so many API's to run within the canvas could this be a new source for hackers to execute arbitrary code. WebGL API's running in the canvas give developers a chance to leverage hardware. What else can be leveraged from within the canvas?

I think ultimately though the canvas tag combined with API technologies will open up a gateway to a new generation of internet. Applications running in the cloud, including gaming applications reliant on OpenGL technology. I think computers will simply become "portals" to the internet. The iPad is possibly a current predecessor.

More on WebGL

• Mozilla WebGL Implementation
• Learning WebGL

WebGL Experiments

• Google Body
• Google "Field"
• Google "Aquarium"