Posts Tagged ‘css3’

HTML5: The right time right place for mobile?

February 9, 2012

Most people by now understand that main challenge for developing mobile applications is creating a solution that runs on as many platforms as possible. This challenge can range from supporting browsers that only support text, up to fully fledged smartphones.

For organisations that are targeting users in the developed world, many are simplifying this challenge to target smartphones only. However even here to create local native applications requires solutions that support Apple’s iOS, Windows, Android and Java (Blackberry).

There are many mobile development platforms available to assist with creating “write once deploy everywhere” apps. The main constrains here are that you end up with deployments to many different stores, and that quite often still write platform specific code to take advantage of platform specific features.

HTML5 has long been a strong candidate for mobile applications, but is it ready? Are mobile browsers upto date with HTML5?

The answer to this question can be a simple “No”, no mobile browser supports the full HTML5 specification. Or a “Maybe” depending on what features (camera, phone book and GPS) of the phone you require you may have support from HTML5.

Push that up to a resounding “Yes”, if you want to move an application that currently runs on the web to run on mobile. Of course, I should also caveat the above with ‘there are grey areas’ in between these responses, not very helpful I know.

For corporates looking to support mobile users with line of business applications I believe there are some great examples that prove HTML5 is ready for them. For a start Facebook is one such application taking full advantage of HTML5, and promoting its use for Facebook apps.

The key areas of HTML5 that are supported across mainstream mobile browsers are offline storage, geolocation, multimedia, graphics (canvas), touch events and large parts of CSS3. The mobile HTML5 site provides a list of mobile browser capabilities.

In the past marketers are argued that presence on App Stores adds value to “brand awareness”, and whilst this is true, there is nothing stopping an organisation having using both native apps and HTML. For example, take LloydsTSB. You can download their app, which effectively once downloaded then runs a “browser” version of their Internet banking service.

There are also some great libraries out there that make cross platform mobile development much easier and provide features that make your web applications feel much more like a native phone app. JQueryMobile is a great example.

So what are you waiting for?

HTML 5 makes the browser smarter

January 26, 2012

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.

Using Polyfill to cover up the cracks in HTML5

October 23, 2011

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.

HTML5 Audio and Video comes as standard

June 26, 2011

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 !

Further reading:
http://dev.w3.org/html5/spec/Overview.html#media-elements

HTML5: The web just got richer

June 23, 2011

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.

Further reading
http://dev.w3.org/html5/2dcontext/
https://www.khronos.org/registry/webgl/specs/1.0/

HTML5 gets fun, without a plug-in in sight

June 16, 2011

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 !

Make sure you use a current browser supporting HTML5 features like Canvas to view / play these.

http://www.google.com/pacman/
http://www.effectgames.com/effect/games/crystalgalaxy/
http://mugtug.com/sketchpad/
http://www.kevs3d.co.uk/dev/asteroids/
http://canvasrider.com/
http://www.benjoffe.com/code/games/torus/
http://agent8ball.com

http://www.beautyoftheweb.com/

HTML5 gets a database

June 9, 2011

As a relative late comer to HTML5 trying to catch up on a spec that spans over a 1000 pages is no mean feat, let alone the fact that the definition of what makes up HTML5 is covered across several specs (see previous blog on standards spaghetti). If you’ve been following this series then you’ll have worked out I have a few favourite features that I think will radically change the perception of web applications, and you guessed it HTML5’s support for database access is another.

The specification started out as early as 2006 with WebSimpleDB (aka WebSQL), and went as far as implementation into many browsers including webkit, Safari, Chrome and Firefox. From what I can find Oracle made the original proposal in 2009 and the W3C made a switch to Indexed DB sometime in 2010. Although Mozilla.org already had their own implementation using SQL-Lite, they too preferred IndexedDB). The current status as of April 2011 of the IndexedDB spec is that it is still in draft, and according to www.caniuse.com early implementations exist in Chrome 11 and Firefox 4. Microsoft have released a prototype on their html labs site at to show their current support .

Clearly it is not ready for live commercial applications in the short term, but it is certainly something worth keeping your eye on and to plan for. When an application requires more than simple key value pairs or requires large amounts of data, IndexDB should be your choice over HTML 5’s WebStorage api’s (localStorage and sessionStorage).

The first important feature about IndexDB is that it is not a relational database but in fact an object store. Hence there are no tables, rows or columns and there is no SQL for querying the data. Instead data is stored as Javascript objects and navigated using cursors. The database can have indexes defined however.

Next there are two API modes of interaction, Asynchronous and Synchronous API’s. As you would imagine synchronous API’s DO block the calling thread (i.e each call waits for a response before returning control and data). Therefore it follows that the asynchronous API’s do NOT block the calling thread. When using asynchronous API’s a callback function is required to respond to the events fired by the database after an instruction has been completed.

Both approaches provide API’s for opening, closing and deleting a database. Databases are versioned, and each database can have one or more objectstores. There are CRUD API’s for datastore access (put, get, add, delete) as well as API’s to create and delete index’s.

Access to the datastore is enveloped in transactions, and a transaction can be used to access multiple data stores, as well as multiple actions on a datastore.

At a very high level, there you have it, IndexDB is a feature that allows you to manage data in the browser. This will not only be useful for online applications (e.g. a server based warehouse could export data cubes for local access) but also for offline applications to hold data until a connection can be established. I’d fully expect a slew of Javascript frameworks to add value ontop of what the standards provide, indeed persistence.js is one such example.

It’s good to see early implementations and prototypes for IndexDB and whilst the date for finalising this spec is unclear, I for one will be monitoring it’s progress closely and waiting with baited breath for it’s finalisation.

http://www.w3.org/TR/webdatabase/

http://www.w3.org/TR/IndexedDB/

http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/

http://trac.webkit.org/export/70913/trunk/LayoutTests/storage/indexeddb/tutorial.html

HTML5 gets cross with domains

June 2, 2011

In my last post I overviewed a number of new communications features in HTML5 that in my mind will no doubt transform web applications moving forward. One of those features was Cross Document Messaging which is one of the most exciting new features I’ve found in the specification.

One of the big constraints of web applications has been allowing separate applications to talk to each other. For example let’s say you have a phone book application and you have a news feed application. If you wanted to show news for a person you selected in your phone book you couldn’t get the phone book to tell the news application which person you had selected, you would have enter the person’s name in the news application and then search: a series of manual steps as automation wasn’t possible.

Along came portal technology, followed by portal standards (JSR168 then JSR286), which enabled applications to do exactly this, share data (of course they have many other features and benefits to). Whilst a portal page can consist of applications (portlets) running off different servers, the main constraint of them sharing data is that they have to be on the same portal page i.e. you couldn’t have two applications running in separate browser windows or tabs and sharing data or passing messages between them.

Cross Document Messaging overcomes this. Essentially an application can use PostMessage to send a message:

 my_iFrame.contentwindow.postmessage(‘Hi there’, ‘http://www.myapp.com/’);

NOTE: you can’t send message from a https to http (or vice versa) application.

 The targeted application must implement an event listener:

 window.addEventListner(“message”, msgHandler, true);

and obviously create the msgHandler function to process the message.

  function msgHandler (e) {…..handling code…..}

The receiving application will be notified of the senders web address (origin) and can therefore choose to ignore the message if it is coming from an unrecognised source. It is best practice for the receiving application to maintain a “white list” trusted origins and check these before processing messages.

Even with trusted origins messages coming in as strings need to be validated as they could contain script and open themselves up to an “inject attack”. This is where the string contains script rather than data, if the script is evaluated it essentially issues a set of commands to the receiving apps server.

The two applications can be in entirely separate browser windows, hence overcoming the constraint of a portlet approach.

The concept of Origins is used by other new features such as XMLHttpRequest. As per my last post previously this API was only able to talk it’s own origin. Now it can talk to other origins, essentially allowing for content to be aggregated in the client rather than just at the server as is the case today.

 This is a simple posting of a powerful capability, certainly an area web developers should consider delving deeper into.

HTML5 gets very chatty

May 26, 2011

The web started birth with very much a “click and wait” experience. Any interaction with the server meant a round trip of data across a slow line and ended up with a page refresh. In the Web 2.0 era things changed dramatically with the exploitation of an API: XMLHttpRequest the foundation of a framework called Ajax. With Ajax web pages could now interact with the server without page refreshes. This was transformational, and especially as bandwidth speeds increased people got very inventive with Ajax and created applications that started to feel much more like desktop applications.

Whilst this created a massive step forward developers were still having to create proprietary approaches, sometimes using plugins, for other forms of communications with the server. Ajax allowed the client to call the server, what about the other way round? And further still how about a server sending a message to multiple clients – either on the same machine but in different windows or indeed to multiple physical clients?

Step forward HTML5 which brings a number of new capabilities for communication. There are plenty of resources that provide tutorials on how to use these new features, the focus of this blog is just to raise awareness of the features and the possibilities they present.

Cross Domain Messaging is one of my favourite features of HTML5 and worthy of it’s own separate article, which I will do in my next post. Essentially Cross Domain Messaging allows you to send messages between separate applications running in separate iFrames, Tabs or even browser windows. It is facilitated by the existing PostMessage api (see next post for more details).

XMLHttpRequest has also been upgraded to support Cross Document Messaging. This now means that an application can communicate with multiple servers. For example imajine a News page that contains an article about Japan, the page may have separate sections containing local weather and currency rate updates. Previously the page would have been built up with content from different sites at the server end, now it is possible to do this from the client. A further enhancement to XMLHttpRequest is the addition of Progress Events. Previously when a request was made to the server there was only the “readstatechange” event, which was limited and no implemented consistently across browsers. Now there are several more meaningful and useful events (loadstart, progress, abort, error, load, loadend) that can be processed

Another constraint the web has faced has been the ability for servers to send messages to clients. The most common example being stock markets feeds. Typically developers have created a polling mechanism to get updates from the server at regular intervals most likely using XMLHttpRequest. This creates unnecessary load and traffic to the server. HTML5 also introduces the concept of Server Sent messages using the EventSource interface.  This is basically a publish and subscribe approach: the client subscribes to a message event source, and the server code publishes messages to those subscribers.

XMLHttpRequest and Server Sent Messages are uni-directional messages, but what if you need bi-directional messages: the ability for either the client or server to send/recieve messages? Well HTML5 also has an answer for that with WebSockets (note it is possible to achieve bi-directional messaging without WebSockets, but it is much more difficult, unreliable and network inefficient)

WebSockets is a large topic, however the key point to be made here is that it is a more efficient and standard mechanism for enabling bi-directional messaging. The first step in the process is establishing a handshake between the client and server, this is done by upgrading from http protocol to the websocket protocol. Where websocket communication provides a significant advantage is that once the handshake is established, communication between client and server is free from the heavy load of http headers! Http headers can reach 2k in size, which is a massive overhead if the message is only 10 bytes.

When you compare this to applications that have implemented a polling approach you can see that WebSockets are not only more efficient in message size but can significantly reduce unnecessary traffic created by polling and reduce latency of updates (created by the polling time).

Using WebSockets today does require a server of which there are many available, and of course like all HTML5 features browser support varies and hence needs to be checked.

This post aimed to key you a flavour of some of the key new features that enable web applications to become more chatty and in doing so not only make applications faster, efficient but richer and more dynamic than we have been used to. I believe just these features alone could drive a new generation of web applications across many industries like gaming and financial services. Could this be Web 4.0 ?

 http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#comms

HTML5 knows where you are!

May 12, 2011

A few years back I was deemed a heretic by many of my colleagues and friends  when I suggested that HTML5 will remove the need for writing many mobile applications. I was pummelled with questions like:

  • But how will they work offline?
  • Are you saying a browser user experience can rival a platform native one like Apples?
  • You do realise that most games require “threading” how you going to do that?
  • What about storing data locally, can you do that?

I was able to fend of most of these, but the one I couldn’t at the time was about accessing the device applications like Camera and GPS. Well things have moved on and whilst I am no longer deemed a heretic there are still some corridor’s whispering doubt.

One of the big features of mobile technology used by many apps is the phones location and location based services and application have already been through a huge hype cycle.

Under the catch-all banner of HTML5, although it is a separate subspec, the W3C Geo Location working group are making location based applications a reality for web developers. It has been around a while and hence is fairly mature and stable now.

A device (even a desktop) can provide location information in a number of ways:

  • IP Address (this is typically the location of the ISP rather than your machine, but ok if you simply want to check which country the user is in)
  • Cell Phone triangulation (only fairly accurate, very dependent on the phone signal so could be problematic in the countryside or inside buildings)
  • GPS (very accurate, takes longer to get location, dependant on hardware support and can be unreliable inside buildings)

Location data can also be simply user defined: however this is dependent on the user entering accurate information.

Of course one of the key concerns will be privacy but the spec covers this with an approach that the requires a user to give permission for location information to be passed to an application. Note the application can only access location information through the browser and not directly e.g. from the GPS device. Hence the browser enforces the user permissions for access.

The Geo Location API allow for both one off request to get the users current location or for repeated updates on the user’s position, developers write simple callback routines for both approaches. The key information provided includes: latitude, longitude and accuracy. Accuracy is a %value of how close the longitude and latitude values are to the user. Depending on the device you may also get additional information such and speed, heading (direction of travel) and altitude.

As per any quality application you process errors accordingly, especially responding to a failure to get hold of location data because of signal issues or other reasons. Hence retrieving location information is fairly simple, the real hardwork is in processing that information and that requires good old fashioned quality programming ;o)

This specification presents a huge opportunity for web developers to create applications once deemed only the domain of platform specific code, and I for one am very excited !

http://dev.w3.org/geo/api/spec-source.html