The unsung hero of the web has always been Javascript, without which the standards-based web would be completely static. Javascript enables functionality to be executed in the browser, and has been used to create all sorts of effects otherwise not possible with HTML alone.
In the early days, Javascript implementations weren’t entirely standard, requiring developers to have to write variants for different browsers; this isn’t really an issue any more.
For applications, developers will either use libraries or develop their own validation routines. This Javascript code adds significantly to the amount of code downloaded.
With HTML5, developers will need to write less Javascript, as the browser provides features to do things for itself rather than rely extra scripting.
Validation is the main area of improvement. HTML5 now provides a number of new validation features such as mandatory checking, type checking, range and field length validation. The validation is done within the browser, and developers can opt to decide how to process errors.
Obviously validation has to be repeated on the server for security, to ensure that data hasn’t been hacked in the browser or in transmission. This then means that validation has to be maintained in two places and kept in sync.
HTML5 also provides a number of new input field types such as tel, email, color, datetime. This empowers the browser, by applying it to display a date picker, or a colour chooser for example. More importantly for mobile applications it would allow the browser to show an appropriate keyboard layout e.g. a numeric layout for tel, and an alphabetic keyboard for email type.
There are also a number of new attributes which previously required Javascript such as autocomplete, placeholder and pattern which will prove very useful.
There will be some organisations that will not want the browser to affect their carefully designed user experience; for these people the answer is simple, just don’t use the new features.
For the rest, you will enjoy having to write less Javascript for HTML5 browsers, but of course you will still need to have backwards compatibility for non-HTML5 browsers which will rely on Javascript.
In the past there have been a number of clever approaches to get around the limitations of web technologies inability to allow servers to broadcast messages/data to clients. One of the more popular libraries for such capability has been Comet.
Whilst providing a solution where the standard lacked functionality, Comet is quite inefficient – both in terms of network bandwidth and performance.
Comet effectively posts a message to the server and the server replies if there is data waiting to go, if there is not the call is left waiting and if subsequently it times out the client is notified which in turn then makes another call. So it’s inefficiency is that it is constantly making calls to the server regardless of whether there is data to be sent back or not. Also it is using HTTP, so the requests are relatively large in size.
In a previous blog, I mentioned how the WebSockets API allows you to have bi-directional messaging between a browser and server. The use of WebSockets requires a Socket server to facilitate messaging using the socket protocol (which is far more efficient in terms of request size than HTTP). The most popular example of a good use of WebSockets is online chat.
The main advantage of SSE is that no additional software is required, a standard web server can be used as it only relies on the HTTP protocol. However, the main downsides therefore are that SSE is uni-directional, server to client broadcast only and, because they use the HTTP protocol, the message requests are much larger than socket calls.
SSE also allows arbitrary events which even allows messages to be sent to different domains. Care needs to be taken as this can be open to abuse, so developers should check the domain from which the event has been generated is one that they are expecting.
This is a powerful capability, and for anyone looking at “lean portal” implementations, could be a way of creating functionality like “inter-portlet communication” without requiring a portal server to facilitate the sharing of data.
They are also relatively simple to implement which again gives them an advantage over WebSockets.
SSE will be most useful to applications like stock ticker’s, live news, weather updates, sports scores and any other applications where the server needs to push data to a client. So does this mean the end of Comet? No because to provide backwards compatibility with non-HTML5 browsers, Comet could be used as a polyfill.
Long gone are the days when Internet Explorer had 95% of the browser market. We have lived in multi-browser world since the start of the web. Whilst this has its plus point, it also has its downsides – none more so than ensuring backwards compatibility. Using HTML5 today is not simply a case of does the browser support it or not, but what aspects of the huge specification does it support and to what extent. A good site for seeing the various levels of support across browser releases, against different areas of the HTML5 specification can be found at CanIUse.com.
The W3C’s answer to developers creating solutions with HTML5 is that the new features of the spec should “gracefully degrade” when used in older browsers. Essentially this means the new markup or API is ignored and doesn’t cause the page to crash. Developers should test and develop backwards compatibility. This can be an onerous task. However help is at hand with libraries like Modernizr you can detect what features of HTML5 the browser supports.
Once you know that the browser doesn’t support a HTML5 feature you have used you can write or use a 3rd party “polyfill”. In HTML, a polyfill is essentially code that is used to provide alternative behaviour to simulate HTML5 features in a browser that does not support that particular feature. There are lots of sites providing polyfills for different parts of the HTML5 spec, a pretty good one can be found here it lists lots of libraries covering almost all parts of the specification.
For me a big concern is that I’ve not yet been able to find a single provider that gives you polyfills for the whole of HTML5, or even the majority of the specification. This could mean that you have to use several different libraries, which may or may not be compatible with each other. Another big concern is that each polyfill will provide varying levels of browser backwards compatibility i.e. some will support back to IE 6 and some not.
With users moving more of their browsing towards smartphones and tablets which typically have the latest browser technology supporting HTML5, backwards compatibility may not be an issue. However it will be several years before the HTML5 spec is complete, and even then there are new spec’s being created all the time within the W3C. So far from being a temporary fix the use of polyfills will become a standard practice in web development, unless of course you take the brave stance of saying your application is only supported on HTML5 browsers.
However this does raise another question, if you can simulate HTML5 behaviour do you need to start using HTML5 at all to create richer applications? The answer is quite possibly not, but having one will certainly improve your user experience and make development of your rich internet applications simpler.
The good thing about standards is that they are uniform across different vendor implementation. Well that is at least the primary goal. So how does a vendor make a standard proprietary?
Well it’s quite easy really you provide extensions to the standard for features that are not yet implemented in the standard. Vendors wouldn’t be that unscrupulous would they? For example would they create application servers following standards but add their own extensions to “hook you in”, sorry I mean to add value beyond what the standards provide ;o)
I’m sure Microsoft’s announcement at Build to allow developers to create Windows 8 Metro applications using HTML5 and Javascript took many Microsoft developers by surprise. What is Microsoft’s game plan with this?
Optimists will cry that it opens Metro development out to the wider base of web developers rather than just to the closed Microsoft community. Cynic’s will argue that it is an evil ploy for Microsoft to play the open card whilst actually hooking you into their proprietary OS. In the cynics corner a good example is Microsoft’s defiant stance of Direct3D versus the open standard alternative OpenGL. This has lead to Google developing Angle, effectively allowing OpenGL calls to be translated into Direct3D ones so that the same programmes can be run on Microsoft platforms.
Whatever it is developers aiming for cross platform conformance will need to stay sharp to ensure that proprietary extensions do not make the application incompatible in different environments.
Adobe’s recent donation of CSS Shaders shows a more charitable approach whereby extensions are donated back to the standards bodies to make the “value added” features available to every platform. This is largely the approach in which standards evolve, with independent committee’s validating vendor contributions.
So what is Microsoft’s game? It’s too early to really say whether there is an altruistic angle on their support for HTML5 and JS, but history has shown us that the empire is not afraid to strike back. Look at their collaboration with IBM on OS/2 leading them to leave IBM in lurch with their own launch of Windows NT. A similar approach occurred not long after with with Sybase and Sql Server.
I maybe a cynic, but having been a Windows developer from Windows 1.0 to Windows NT and following a road of promises and U turns has made me that way when it comes to Microsoft. It’s great to see increasing support for HTML5 but I am always a little concerned with the motivations of the Redmond camp. However perhaps I myself need to be “open” to a different Microsoft, one that is embracing standards even though it may cannibalize it’s own Silverlight technology.
At the time I thought this was a brave statement to make especially as the late Steve Jobs had already announced in April that year and despite a billion app downloads, that HTML5 negated the need for many proprietary browser plug-ins. It was clear at the time this was squared largely at Flash (and possibly Silverlight too).
For me this was a faux pas too far as Huggers continued his blog with statements about proprietary implementations of HTML5 by Apple and fractions of opinions within the W3C and WHAT-WG (who initiated the development of HTML5).
Now fast forward to almost exactly a year later, and Gideon Summerrfield, Executive Product Manager for BBC iPlayer announces the launch of a HTML5 version of iPlayer. Initially this is just aimed at PS3, but will roll out to other devices in the future.
If we take a slight diversion and look at the developer conferences for both Microsoft and Adobe in the last four weeks, both made big announcements about tools and support for HTML5. However committed developers with years of invested skills in SilverLight and Flash were left deflated with the lack of announcements on the future of these technologies.
So have the sleeping giants finally woke up? It seems like it to me.
However, in the case of the BBC, Summerfield’s blog states that they will also launch new versions of the iPlayer for Flash and Air. This may be a short term decision to wait for wider support for HTML5, but there is little clarity about what they see as the future for iPlayer.
To Hugger’s credit he did foresee the benefits of HTML5 could bring to the BBC in reducing development timescales and having a common skill set.
However I applaud those that have the courage and conviction to take bold steps forward and put their money where their mouth is. The FT is a shining example, ditching their AppStore versions for iDevices and completely moving to HTML5.
There is work to be done on HTML5 and it will evolve for some time yet, but the bandwagon has started to roll and as a good friend of mine said to me at the start of the .com era, “When you see the bandwagon starting to move, you have a choice to jump on, or stand in the way of a tonne of metal !”.
For me it is clear. I’m not standing in the middle of the road, I’m jumping squarely onto the HTML 5 bandwagon. The question is, are you?
Since the early days of the web, marketeers have espoused the merits of “managing customer experience” and how online it is only the “experience” that will differentiate companies as the web brings pricing transparency. Certainly in the case of the latter issue, the rise of “comparison” sites has highlighted the fact that price alone can not be a long term strategy. Post the Internet bubble bursting the issue of customer experience has for many had to take a back seat while organizations strove cost cutting measures to remain profitable or even just to survive in the midst of recession.
However more recently it seems that customer experience is again getting more prominence and importance in organizations. I believe mobile has had a role to play in creating this renewed excitement with the apps showing “the art of the possible”: engaging user interfaces with greater usability. It’s no surprise to see experience champions rallying their brethren troops to create their own community of professionals in the field. Founded by Bruce Temkin (previously an analyst at Forrester) , the CXPA (Customer experience Professionals Association) is a organization focused on creating standards and best practice in Customer Experience Management. As a non profit organization it’s sponsors in Adobe, Microsoft and SAP. Whilst it is early days there are enough credible people involved to make this a success in an area which sorely requires standards.
But what really captured my attention this week was an announcement by US Insurance company Mass Mutual, appointing a Chief Customer Experience Officer, the remit of this role is to manage “central oversight of the end-to-end experience for MassMutual customers to ensure a consistent, favorable and efficient interaction across the organization”. What’s interesting about this is that whilst most C level directors recognize the importance of customer experience, very few actually have someone in their company whose prime responsibility is managing customer experience.
So well done to Mass Mutual and hopefully we see many more similar appointments, in the meantime however the CXPA or someone of the same ilk needs to bring some much needed standards and best practices to a field crowded with self proclaimed “experts”.
My previous posts about “The end of Silverlight” and “The end of Flash” both raised active debate. The general view was that I knew too little about Silverlight and Flash to make such brash claims and whilst there is some truth in that it also transpired that the general awareness of what HTML5 can do today, and what it promises when complete is poor, and that is the issue that my run of posts on HTML5 has really sought to address. Hopefully for those that haven’t had any exposure to HTML5, my posts have been of value.
The longer term is much more difficult to forecast, there is a place for both especially for rich multimedia applications and gaming, but for business applications there is going to be small minority of applications that could possibly require them. In the report by Gartner (“The (not so) Future Web”, they too agree saying that “Gartner expects leading RIA vendors to maintain a pace of innovation that keeps them relevant, but for a gradually shrinking percentage of Web applications.”
However one can’t completely ignore that web technology is evolving fast and that new spec’s are filling in the gaps for HTML5 already for example work is already in progress for TV and Gestures as well as previously mentioned 3D graphics. We are seeing major new releases of browsers with greater support for HTML5 being launched at a faster rate than ever before, coupled with a battle for the fastest JavaScript engine. A new release of JavaScript promises much better standardization as well as new features.
The developer forums are now awash with an outcry from loyal Microsoft developers demanding to know the future of Silverlight in Microsoft’s grand plans, where once there was no doubt that Silverlight is core to Microsoft. IMHO I doubt Microsoft will make a U turn on Silverlight, but I will re-iterate that the need for Silverlight in business applications will lessen as HTML5 matures.
Whilst I’ve been an active follower and advocate for HTML5, what I see lacking is a roadmap and vision for HTML, a lot more detail about how the semantic web will evolve and what it means to developers in the short and medium term. This is something the vendors seem much better at and is no wonder developers buy-in to certain technologies over others.
In the end as always the real question is not which is the better technology but what is the appropriate technology for what you need to achieve and the audience and platforms you are targeting.
Movie and Audio features in HTML5 are like many of the features I have discussed previously, they:
• Have a history of controversy over Codec support
• Specifications are too large to do real justice in these short posts
• Are an exciting, powerful new addition that will transform the web
To date the most popular media player on the web has been Adobe’s flash player, and arguably it has been it’s most popular use. Apple’s lack of support in their devices for Flash has created a small crack in Adobe’s party, but this crack could open further into a chasm that their flash drops into! However there have been many other shenanigans in this story and rather than delve into to those murky stories I’m going to again give a brief overview of the capabilities of these new features. The good news is that HTML5 will remove the need for proprietary plug-in’s like Flash and Quicktime for playing sound and movies.
audio and video are both media elements in HTML5, and as such share common API’s for their control. In fact you can load video content into an audio element and vice versa, audio into a video element – the only difference is that the video element has a display area for content, whereas the audio element does not. Defining an audio element and source file is pretty straightforward
<audio controls src=”my musicfile.mp3”
My audio clip
</audio>
You can actually assign multiple source ( src ) files. This is to allow you to provide the audio in multiple formats, so that you can support the widest array of browsers. The browser will go through the list in sequential order and play the first file it can support, so it’s important you list them in order of the best quality first rather than by most popular format.
To load a movie you simply replace the audio element with video. Video’s can also define multiple sources. You may additionally specify the height and width of the video display area.
Next to control media you can use the following API’s: load(), play(), pause(), I think what they do is self explanatory. canPlayType(type) can be used to check whether a specific format is supported.
Some read only attributes can be queried such as duration, paused, ended, currentSrc to check duration of the media, whether it has been paused or ended and which src is being played.
You can also set a number of attributes such as autoplay, loop, controls, volume to automatically start media, repeat play the media, show or hide media controls and to set the volume.
These aren’t exclusive lists of API’s or attributes as there are many more but they are some of the most common features of the audio and video people will use. With video especially there are many more great things you can achieve like creating timelines and displaying dynamic content as specific points in the video (no doubt this will be used for advertising amongst other more interesting uses).
Clearly the web will get richer with full multimedia content without the perquisite of plug-ins. However developers should be aware of the various formats supported by specific browsers and aim to provide media in as many formats as possible.
Many sites today do use sound and movies, but I believe with native support and greater imagination a new world of dynamic rich media sites will change the user experience in the same way that Ajax transformed static content into the dynamic web. With it we will see new online behaviors, a topic I will cover soon, and whilst some have said the future of TV is online the web may just give it a new lease of life !
HTML5 graphics features will drive gaming and rich media to the web
My post about HTML5 games is a great way to experience one of the features in HTML5 that will no doubt make a huge difference to browser experiences. It’s hard to imagine in our rich multimedia world that without proprietary techniques or plug-ins that web standards do not support the simple task of drawing a line, box, circle or any shape! All that is changing with HTML5 with the Canvas API.
<canvas> </canvas> This is the basic canvas element notation which will set the world web alight with animation and richer experiences. It is already transforming the art of the possible in gaming on the web. The original 2D API was created within webkit by Apple who then provided it to the standards body with a royalty free patent licence. In February this year the Khronos Group issued version 1.0 of it’s WebGL API providing 3D rendering capabilities within browsers.
So what is a Canvas? A canvas is essentially a rectangular area on the screen that you can add and manipulate graphics. Simple? If only. The basic action of drawing a line requires: creating a canvas, getting the canvas context, starting a path (beginPath()), defining a start point ((moveTo(x, y)), moving to the end of the line (lineTo( x, y )), closing the path to say we finished drawing our line (closepath()) and finally drawing the line (stroke()). If this sounds complex let me tell you that to do even this simple action previously involved some very imaginative code and image manipulation.
You can create simple or complex shapes using “paths“. Drawing a line following the path only occurs when you call stroke() . If the path create a shape it can also be “filled” using fill() . A fill can have colours and styles (e.g. a pattern, gradient or image).
With more curvy shapes you need to look to quadraticCurveTo(), bezierCurveTo(), arcTo() and arc() to create a path that curves.
Apart from drawing and colouring (“filling”) images can be transformed: scaled (scale()), rotated (rotate())and skewed (transform ()).
Apart from shapes, of course you can draw and fill in text on the Canvas. And there are also API’s to create set the attributes of shadow’s: shadowColor sets the color of the shadow, shadowOffsetX and shadowOffsetY positions the shadow from the original shape or text and shadowBlur allows you to blur the shadow.
There is so much more that can be said about Canvas that I almost didn’t bother with this simple overview for fear of not doing it any justice. However in the end I felt it needed a mention. The latest draft of the specification can be found here. Beyond this WebGL will provide a whole new set of more powerful capabilities however it is currently way behind the basic Canvas features in terms of browser support.
I’ve still not finished covering all the new features of HTML5, but I do think it’s time for a bit of a break. One of the real measures of whether HTML5 will take off will be how well it will support the gaming industry, and indeed here some people have feared that it will not deliver and have continued to back plug-in based technologies like Flash, Java or Silverlight. Well after extensive research it’s time to dispel a few myths
.
Now it’s not true that there haven’t been some great HTML games already, remember Google’s re-incarnation of PacMan and recently Effect Game’s Crystal Galaxy which will work even in IE6 !
However a number of features like Canvas, HTML5 Audio and WebWorkers are changing people’s perception of what is possible on the web and all without plug-ins ! So here is my top 5.
In at number 5 is, well not a game, but nevertheless a nice use of the new canvas API’s, a remake of the popular windows desktop app, Paintbrush.
At number 4 is another remake of an old classic, Asteroids! Whilst not up to the standard of today’s modern graphics they are a vast improvement over the games original line art graphics, and offers smooth movement and responsive feedback.
Number 3 is Canvas Rider a simple yet strangely addictive game requiring skill and judgement to guide a motorcyclist across a number of different scenes.
Just missing the top spot is Torus a 3D cylindrical version of Tetris.
However in first place has to be Pixel Lab’s Agent 8 Ball, great graphics, fast smooth operation and sound make it hard to believe that this is a browser game without any plug-in support. In fact this video comparison of Flash vs HTML seems to have totally missed this great example too (see comparison of pool game 3mins in). There are many more great examples out there, even for those Silverlight enthusiasts Microsoft has assembled some great examples of HTML5 in action.
So what’s the future? Well if Google’s demo last year of it’s web version of Quake is anything to go by things are certainly looking exciting ! The future is definitely not solo game play, as Game Closure showed last month when it demo’d a multiplay social game called Popstar Defense.
All the credit for this new world of possibility can’t just go to HTML5/Javascript as technologies because it is the tremendous improvements in Javascript engines by all the main stream browser providers that is giving the games a useful performance boost.
I’ll be covering some of the HTML5 features that enable these games such as Canvas and HTML5 Audio in future posts, enough research for now… time to get back to work !
