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.

Using the ‘progressive enhancement’ methodology, we build a website that works in all browsers first, then ‘layer on’ the cool features and ‘nice to haves’ after, so users with modern browsers get the full site experience and older browsers still have access to all the content. CSS3 sits in the ‘nice to have’ category for the moment.

While looking through the W3C CSS3 Working Draft I came across a section called ‘Inserting content into an element’. The CSS3 pseudo-elements listed here are used to add content to the page using CSS. Cool! ….wait a second; for years we’ve been separating layout from content, allowing us to easily edit a whole website layout from a single file. The pseudo-elements seem to be going against this mantra! Uh ohh! It’s controversial, but I believe if used responsibly the pseudo-elements shouldn’t cause any major accessibility issues.

::before & ::after
The ::before and ::after pseudo-elements are used to add content before and after the content inside the selected element (surprising huh!):

View a demo here.

The specifications even allow you to add more content by iterating the pseudo-elements, so ::after::after (or ::after(2)) but this isn’t supported in current browsers I have tested. I’m personally hoping that part of the specification isn’t implemented, as you can have too much of a good thing. You could end up in the nightmare situation of pages completely generated using CSS3 using multiple levels of ::before and ::after.

The CSS3 specification has also outlined the pseudo-element ::outside but it hasn’t been implemented yet in the current version of Firefox I’m using (3.6.3).

Outline will allow you to wrap an element inside another element and then add styling to it. Usually you’d modify the source code by adding extra divs to do this, but it isn’t always possible. Outline would have been very useful over the past couple of years for adding ‘sliding doors’ and rounded corners where needed, without having to clutter up the mark-up with ‘for style’ only tags. Oh well it’s a tool for the future.

I can’t say I’m a big fan of these new pseudo-elements as they seem to be stepping on HTML’s toes. It’s hard to think of a situation where you’d want the CSS to be writing content to the pages since it isn’t accessible to screen readers or search engines, but I’m sure there are some. The only example that springs to mind is when you add a ‘:’ after the label on a form field, you don’t want a screen reader to read out the ‘colon’ so you add it using CSS.

I’d love to hear where other people plan on using ::before and ::after, or where you are using them at the moment.

The Audio Data API is a draft extension specification that allows developers to read and write raw audio data. As it’s only a draft specification I’ve had to use a custom build of Firefox 3.7 with the extension hacked into it (which you can download from here). The visualisations rely on a custom browser event displayed here:

The onaudiowritten event fires when audio is played, the raw data is passed to a pre-calculated FFT (Fast Fourier Transform) from which you can start generating your visualisations; it is then written to the audio layer for users to hear.

Here are 6 visualisations I've built, using the modified version of Firefox you can switch between them with live data.

You can view a demo of my visualisations, or for those of you who don’t have the custom version of Firefox installed I’ve created a short video of them in action. Each visualisation lasts approximately 10 seconds before changing. The music is courtesy of a friends band called ‘Good Dangers‘.

I hope the Audio Data API is approved and other browsers implement it, as it’s an exciting use of browser technology and defiantly an area I’ll be keeping an eye on.