So what exactly do the Fullscreen and Pointer Lock API’s do you may ask. Well Fullscreen is obvious; it allows you to view any web content in fullscreen mode, removing the browser UI for distraction free reading. Pointer Lock gives a developer access to raw mouse movement data, not just the absolute position of the cursor. You are no longer limited to the size of the browser window, so you can scroll continuously in one direction without having to stop. Where both of these API’s come in very handy is the development of HTML5 games. It’s now possible to create a games like Quake 3 directly in the browser with usable controls… impressive!

To have a play with both API’s I put together a little experiment using three.js and a panoramic image.

What a beautiful day in Sydney, just round the corner from where I live.

I started by building on an excellent blog post by Paul Lewis called “Create your own environment maps”. Using Microsoft’s Photosynth App and Blender it’s dead simple to create a panoramic image. After adapting Paul’s code to my needs, I added the Fullscreen and Pointer lock API’s. To enable Fullscreen mode press enter. If you have a compatible browser, the browser UI will disappear and you will enter fullscreen mode. If Pointer Lock is available, a prompt will appear asking for permission to hide your cursor. You will now be able to scroll left and right continuously without having to stop, if Pointer Lock isn’t available the demo will drop back to standard mouse co-ordinates.

A quick tip for working with both of these API’s: use a shim like that made by Brandon Jones, it will save you a lot of cross browser pain! Browser vendors are still changing the way both of these API’s are implemented, so until this stabilises, using a shim is the way to go. Big thank you to Paul and Brandon for their excellent contributions.

Well there is a jQuery plug-in called Mobiscroll which is around 16KB is size and works on iOS and Android devices. Unfortunately there’s no mention of Windows-based mobiles which is a real shame, as it’s almost a perfect solution. The other option we have is to take advantage of some cutting edge HTML5 form input types; the date input type. Support is nowhere near 100% yet, but if you approach its usage from a progressive enhancement standpoint, it works well. On mobile browsers that support it, the user gets a fancy datepicker that’s very intuitive; browsers that don’t simply drop back to a standard text input. It’s worth noting that Modernizr can’t detect that date inputs create a datepicker, since Modernizr can’t do it I assume it isn’t possible. Damn!

The date input type as displayed on iOS mobile Webkit devices.

Once I’d decided on how the date picker was going to work (HTML5) it was time to implement it and test it across my available mobile browsers. Implementation was dead simple:

Where things got a little tricky (and annoying) was the client-side validation of the input. Since the wireframes contained lots of forms with a varying range of input types and requirements, I decided to go with quite a heavyweight validation script (around 21KB minified). This turned out to be a very good decision in the end, as there are a few quirks to the date input element.

First thing I had to consider was how were users going to input the date when they don’t have the fancy datepicker? The most intuitive way (at least for me) is they simply enter in the format dd/mm/yyyy. Great, that’s sorted! And guess what, when a user uses the fancy datepicker it also returns a value of dd/mm/yyyy…. no, no it doesn’t! It looks like that’s the value that will be returned as that’s how it is displayed, but no, it’s never that easy. Webkit actually returns the date in the format yyyy-mm-dd, not quite what I was expecting! Unfortunately this breaks our validation as it is looking for a format of dd/mm/yyyy!

So what’s the fix? Well you could take the easy route and make your non-fancy datepicker users enter the date in the yyyy-mm-dd format; but that just feels wrong. No user is going to expect to enter a date like that, it’s completely unintuitive! No I’m afraid it’s going to take a little hack to fix this issue. The hack involves using a second input field of type “text”; when a user interacts with the fancy datepicker or enters in the date manually, the date is “cleaned up” and passed along to the second input field. You then do your form validation against this second field. You can see an example of this working here.

A couple of points to note about using this method. Even though we aren’t validating the datepicker input, we still have to set “date: false” in the validation rules. This is because the validation plug-in automatically tries to validate date inputs. Validation fails because it doesn’t like the dd/mm/yyyy format. I’ve also used the dateITA method to validate the date on the “hidden” input (you can find this in the additional-methods.min.js file). This additional method is more robust than the plug-ins standard date validation. A minor pitfall with this hack is that setting the second input to type “hidden” will stop its validation; this is due to the validation plug-in ignoring hidden inputs. So to hide the input you can set “display: none” in the CSS (urghh I know, I feel dirty too!).

So there you have it, that’s how I solved validating a date input on mobile with fancy datepicker and standard text fallback. It’s not ideal by any means, but it works. Another solution would be writing a validator Regex that accepts both dd/mm/yyyy and yyyy-mm-dd date formats, but this means returning both types of dates to the server on submit. Due to server-side constraints with the project, this isn’t an option (boo!). Is there a much simpler method that I’m completely missing? If so please leave a comment! :)

After a little head scratching to work out what was failing, I worked out it was because I was using HTML5 elements such as ‘article’, ‘header’ and ‘footer’. There was no problem displaying them on the page, as I’d used Remy Sharps excellent HTML5 Shiv script. It only failed when trying to pull in these ‘new’ elements via Ajax.

Note: Before you read on you’ll be happy to hear that this issue no longer occurs in jQuery 1.7.0. Horray!

If you can’t upgrade, for whatever reason, I hashed together a little work-around for browsers IE8 and below, so read on. I admit the work around isn’t pretty, but it works. I tried for a few hours to get IE8- to recognise the ‘new’ elements after an Ajax request, but to no avail. Eventually I had to wrap the HTML5 tags in a div using conditionals:

The div is added for browsers IE8 and below, you can then use it as a hook to pull in the elements inside the div. I was hoping that wrapping the HTML5 elements in a standard div would be the end of it, I’m afraid not. The .load() method still didn’t work, IE just ignored the elements it didn’t recognise. I used jQuerys much more customisable .ajax() method to fix the issue in IE6, 7 and 8:

This method works in all browsers I’ve tested in as I’ve added a fall back (or should that be forward?) for newer browsers. The solution isn’t ideal (I really hate the conditional comments), but older versions of IE aren’t going away any time soon, and it works. Maybe there’s a more obvious solution that I missed? Leave a comment if there is, I’d love to know!

You can see a working example here. The page I’m loading from is here and the JavaScript in full here.

I’ve been a long time user of Firefox’s magnificent Firebug extension; I honestly cannot remember how I used to develop websites without it (can you?). Changing web pages on the fly and debugging issues in seconds rather than minutes, we really are spoiled. I thought it would be hard for any other debugging tool to come close to Firebug in terms of ease of use and available tool set. Oh how I was wrong!

Paul Irish and Pavel Feldman hosted a talk at this years Google I/O about Chrome Dev Tools and what’s new in the world of debugging in Chrome. I must admit, there were a number of jaw dropping moments in the video where it dawned on me how powerful the tools actually are. Here are a few of my favourite points:

• 7:11: Chrome monitoring the changes to the style sheets and letting you know what has changed.
• 7:55: Ability to revert back to different CSS versions. The Dev Tools automatically creates a new version as you change code.
• 21:02: A whole host of JavaScript debugging tools. Edit the script in the browser (with code colouring.. nice) rather than edit in IDE, upload, test, repeat…
• 30:31: My favourite part, the remote debugging feature. Chrome can act as a server meaning you can connect too and edit pages remotely. At first you may think “well, what’s the point?”. As this is being done at the WebKit level it will soon be available for all WebKit browsers including mobile devices. Debug mobiles browser directly from your desktop. Wow!

I’m definitely going to have to wean myself off Firebug and give the Chrome Dev Tools a blast. As mentioned in the video, the tools are being developed all the time with new features landing daily (on dev channel). Looks like Firebug has some serious competition! If you’re a developer with 43 minutes to spare, watch the video, you won’t regret it.

A few helpful links mentioned in the video:

• Lea Verous CSS3 pattern gallery
• Full documentation for Dev Tools
• The slides – Chrome Dev Tools: Reloaded

What’s always amazed me about these demos is the amount of space the programmers had to play with and the hardware available at the time; both extremely limited. While the space and hardware limitations are no longer an issue, people are still developing these amazing demos. One reason for this is due to an exciting area in Web Development that’s currently flourishing: WebGL. The technical specification was finalised last week and developers have started to take notice of this very powerful visual programming language. Developing demos in the browser environment is a new limitation and programmers are looking at WebGL to push the boundaries.

WebGL port of "glass", an old 64kb demo from 2000.

The demo above has been converted into WebGL by a very talented programmer called Per-Olov Jernberg (Possan). You can even take a look at the source on Github if your that way inclined! You can view the original from April 2000 here.

With modern browsers like Chrome, Firefox 4 and now Opera adding WebGL support and improving their JavaScript engines, there’s never been a better time for Web Developers to get involved in this new demoscene. All that’s needed is some JavaScript, Canvas and a little creativity. I genuinely look forward to seeing all the old school programmers diving into WebGL. I personally know very little about this new language so I’ll be able to learn so much by doing a quick “view source”.

There’s already a WebGL competition in progress called gl64k where programmers have to create an interesting visual demo with only 64k (65,536 bytes) at their disposal. Awesome stuff will be emerging from this new technology in the next couple of years and I for one can’t wait to see what!

It really is that simple! You may notice the “x-webkit-speech” attribute so will have guessed it currently only works in Webkit; and as far as I’m aware only in very recent versions of Google Chrome (note: “The Input Speech API will now be available by default on Chrome’s dev-channel”). The Speech API seems very new and is still a draft, so it will be a while before it’s fully adopted by other browser vendors.

A quick demonstration of the Speech API in action.

To demonstrate the speech input I’ve put together a very simple festive demo that queries the Flickr API looking for images related to a value entered. So if you have a microphone and the dev channel of Chrome, why not give it a try. Chrome records the input of the microphone before sending it off to an external server to be processed, where a value is then sent back to the browser. At first I thought it was all processed inside the browser but I guess that’s a little to much to expect! It isn’t 100% accurate and the demo accepts Googles first guess so you may get a few strange results. The server returns multiple guesses which a user can select from, but this hasn’t been added (to my demo at least).

Since the API is very new it took a little trial and error to work out how to detect if the Speech API was available in the browser; but with a little help from Paul Irish I managed to crack it:

This function will return true if the API is available. It’s worth noting that since it’s very new this function is likely to break in the future as the properties always seem to be changing. It works at the moment, so get thinking about what this brilliant new API can be used for! It’s a big plus for accessibility if used correctly and I can also see some cool applications in web gaming too. View the demo.

Mr Doob has created a superb JavaScript 3D Engine in three.js. Screenshots from my 'Bowl' demo.

I’ve been watching the development of three.js by Mr Doob for a couple of months and have been desperate to experiment with it. With Firefox 4 well into the beta stage I decided to bite the bullet and do a little Audio Data visualisation in 3D!

I’ve dabbled with audio visualisation and the HTML5 Audio Data API in the past, so I’m pleased I’ve had a chance to use it again and see what’s new. Note: My previous audio visualisations using canvas no longer work due to specification changes in the API. A pitfall of using an API that’s still in the draft stages I guess.

I’ve put together 5 simple demo’s all based around the same theme showing some of the options available in three.js. My favourite is “bowl”, pretty colours galore!

• Circle: Simple circle, zoom in / out using the mouse wheel.
• Cubes: Same as circle only using the cube primitive.
• Cylinder: Using the cylinder primitive with a floating camera.
• Sinewave: Rotated sinewave (looks a little like a chandelier).
• Bowl: A combination of the above demos to create an interesting 3D bowl effect.

Please note these demos will only work in Firefox 4. The Audio Data API is still a draft specification and Mozilla is the only browser vendor to have added it to date. I’m looking forward to it being added to Chrome (Webkit), with its superb V8 JavaScript engine. The demo’s really are just the tip of the iceberg for both three.js and the Audio Data API. It’s certainly an area of the HTML5 specification to keep your eye on.

The music track used in the visualisation is called “Sad Robot” by a group called “Pornophonique”. Very catchy tune that you can download from Jamendo.

Update: It looks like enabling the Google Page Speed Apache module seems to have broken the demos. I’ve disabled it now so it should hopefully fix it (fingers crossed!).

1. IE9 is still only a preview release, not a complete browser.
2. When released IE9 will only work on Vista and Windows 7.

Point 2 is unfortunately a big party pooper. Windows XP is the operating system that refuses to die, 48% of users who visited W3schools in October were on XP. That’s a large percentage of people who are excluded from installing IE9. We can always hope that these users are using a standards compliant browser from another company (Firefox, Chrome, Safari, Opera) but that may be a little optimistic.

So, even though IE9 is a huge step forward by Microsoft, it doesn’t look like older versions of IE are going to die out any time soon. Luckily the UK government are forward thinkers… wait, no, that’s a lie. So the browser that’s been crippling the web for the best part of a decade looks like it may be around for another 10 years. I’ll put the party poppers back in the draw then.

HTML5 has added a host of new tags which have much more semantic meaning. So instead of using ‘divs’ to section off areas of your page layout, you can now use:

It’s certainly a welcome addition to the modern web. My favourite part of HTML5 has to be the doctype (other than the canvas element):

Look how simple it is! No more copy / paste from a previous project for this doctype.

My main concern when converting the theme to HTML5 was how it would work in IE; as IE8 supports parts of HTML5 but IE6 and IE7 not at all. When IE comes across a tag it doesn’t recognise it just ignores it. Since the tags aren’t recognised you won’t be able to style your lovely new HTML5 template in IE6 & IE7. Lucky you can patch this missing functionality using JavaScript. Remy Sharp has created a script called html5shim, that adds the missing tags to IE. Just add the following code to your header and you will now be able to style your HTML5 tags:

The script must be in the header and must fire before the DOM is created. The script simply creates all the new HTML5 elements using the document method ‘createElement’, you don’t even need to attach the created elements to the DOM! Now IE will recognise the tags and you can get on with your page styling. Yay!

Those who use WordPress 3.0 may have noticed that the default Kubric theme is no more and it’s been replaced with a new theme called twenty ten. The theme uses the HTML5 doctype but it doesn’t use any of the new tags. I guess because of the IE issues. Maybe this will be changed in future releases.

The Nooshu theme is still a work in progress, and I’ll modify areas as I learn more about the new HTML5 features. Here are a selection of links that I found incredibly useful while working on the theme:

• Dive into HTML5: Read through this article and you will be well on your way to learning HTML5. It delves into the history of HTML and progresses forward right up to implementing the new specifications.
• HTML5 Doctor: Looking for HTML5 related news or need some clarification of a new tag? Look no further than HTML5 Doctor. Lots of articles available for you to read and there’s even the option to ask a question if you don’t find the answers you are looking for.
• HTML 5 Outliner: So you’ve created your shiny new HTML5 template; why not check it with the outliner to see if it makes sense to a user / search engine.
• W3C Markup Validator: It’s been a while since I’ve used a validator since I have one built into Firefox, but the W3C validator was very handy for pointing out attributes and tags that are no longer supported in the specifications. It also gives you a quick benchmark to aim at.

If you have any other useful HTML5 tips and links let me know below.

If you are a Gmail user I highly recommend creating an application shortcut to see this function in action. One thing you will notice when you create the shortcut with Gmail is it uses a high resolution icon. If you create a shortcut using a standard website, by default the favicon.ico is used. As the favicon is limited to 16 by 16 resolution it will look very ugly blown up on your desktop.

You can really see the difference between the Gmail icon (left) and the standard favicons.

The image above really illustrates the difference between a 16 x 16 icon and a high resolution version. Now of course you could just change the icon in the Windows properties…. but that’s boring. Why not offer your users a high resolution image along with the standard favicon? It really is very simple:

Simply place this code in your head tag of your web application and link to the corresponding icons. Now when your user creates an application shortcut they will have a nice high resolution icon on their desktop.

You can really see the difference when you add a high resolution icon

I’ve added a high resolution icon for my blog administration, now if only F1 live timings would do the same. For those of you who want to add a high resolution icon to your WordPress blog add the following code to your functions.php:

This will add the icon code to your administrator login panel and dashboard; or paste the raw HTML into your header.php so all users can see the icons.