nooshu - Matt Hobbs' Web Development Blog

Kneeling on the shoulders of giants

Category: Browsers

Any browser related topics relating to browser performance and bugs.

Remote Loading HTML5 Elements with jQuery

I ran into a rather annoying problem a few months ago while developing my travel blog; the problem of course was involving Internet Explorer. I’m used to working with WordPress as I use it all the time, but I wanted to get away from the standard pagination you find on a blog. So I decided to use jQuery 1.6.4 to pull in articles from other pages (blogname.com/page/2, blogname.com/page/3 etc). Now this is all fairly simple using the handy jQuery .load() method; point it to a URL, pull in the page, pick the bits you need and reinsert into the page. Simple! Unfortunately once I got a prototype working in ‘good’ browsers, IE8 and below was having non of it!

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
<!--[if lt IE 9]><div id="ieHackContainer"><![endif]-->

<article id="html5Content">
    <header>
        <h2>H2 wrapped in a header element</h2>
    </header>
    <!-- Other HTML here... -->
    <footer>
        <p>This is the footer element</p>
    </footer>
</article>

<!--[if lt IE 9]></div><![endif]-->

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//IE8- work around to load HTML5 elements into a page
$("#loadHTML5LinkOld").click(function(){
        $.ajax({
                url: "page_to_load.html",
                cache: false,
                success: function(html){
                        var HTML;
                        //Clear before load
                        $("#html5LoadHolder").empty();
                       
                        //IE: Look for the hacky wrapper before insertion
                        HTML = $(html).filter("div#ieHackContainer").html();
                       
                        //If HTML var is empty assume using newer browsers
                        if(!HTML){
                                HTML = $(html).filter("#html5Content").html();
                        }
                       
                        //Append to page
                        $("#html5LoadHolder").append(HTML);
                }
        });
       
        return false;
});

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.

Chrome Developer Tools at Google IO 2011

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:

The developing WebGL demoscene

One of my key memories from playing a friends Amiga oh so many years ago (apart from Cannon Fodder) is the cool intro demos created by the demoscene. These were usually found on, cough, slightly dodgy versions of games that were “acquired” from various sources :)

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.

The demoscene in action via WebGL

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!

Experimenting with Webkit form speech input

It’s been a few weeks now since I attended a Web Gaming event hosted by Mozilla and I’ve not yet had chance to write about one of the coolest features that was demonstrated: Speech input in forms. Now I must admit, I had no idea this was even possible; so it was quite a surprise when I saw the demonstration. With a few extra attributes added to a standard input box you can enable speech input:

1
<input name="speech" id="speech" type="text" x-webkit-speech speech error onwebkitspeechchange="dosomething.coolhere(true);" />

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.

Demo of the new HTML5 Speech API

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:

1
2
3
4
5
function speechcapable(){
    var elem = document.createElement('input');
    var support = 'onwebkitspeechchange' in elem || 'speech' in elem;
    return support;
}

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.

Three.js and the Audio Data API Visualisation

3D audio visualisation

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!).

Currently on page 1 of 41234