URL Hunter

If you enjoyed playing Rogue or other ASCII art based games then I'm almost certain you'll enjoy URL Hunter. It's certainly worth a 30 second diversion from whatever else you are currently doing.

Following Prototype Through The LightWindow

So I've finally got the new layout mostly working. It's a combination of the XML layout from my book blog and the original style sheet from the HTML version of this blog. In other word, if you were to take a look behind the curtain you'd find that it's a real mess! Anyway now that I have something that kind of works I can slowly tweak it and tidy things up, hopefully, without anyone noticing.

There were a few problems with the conversion to the new layout, but one in particular, caused me no end of problems and so I thought I'd explain the problem and detail the solution. As a bonus if you read through this you might just understand the title of this post!

One of the reasons for upgrading the blog template was that I couldn't use any of the widgets with the HTML layout, and I wanted to be able to add a blog list and the followers widget. So once I'd replicated the old layout I started to play with the widgets. The blog list worked a treat and so you can now see the last post from my other blogs under the "I'm Also..." heading, but when I added the followers widget I just got a blank space. I knew the problem wasn't with the followers widget as such as it was working fine on one of my other blogs. Given that behind the scenes most of the widgets use a fair amount of JavaScript I assumed, rightly as it turned out, that one of the scripts I was loading was interfering with the followers widget. The problem was which one.

As well as any JavaScript loaded by any of the other widgets on the page or added by Blogger I also load nine other JavaScript files in the head section of the template. These provide support for embedding QuickTime videos and Google Maps, providing syntax highlighting on code snippets and the fancy popup display when you click on an image. Some of these are a single JavaScript file, others require multiple files to be specified, and some even dynamically load extra files as needed. Not knowing which of these was the problem I started by removing everything and low and behold the followers widget appeared correctly.

So I added back the JavaScript includes one at a time until the followers widget disappeared. This led me to the culprit -- prototype.js. Apparently "Prototype is a JavaScript Framework that aims to ease development of dynamic web applications". Now I don't use Prototype directly within the layout but it is used by the LightWindow script that I use for showing the large version of photos. I didn't know exactly what the problem was so I tried upgrading to the latest version of Prototype (v1.6) but that didn't help. I then tried the release candidate for the next version and the followers widget appeared. Unfortunately the LightWindow script didn't work properly -- I think there is an issue determining the correct size to scale the image to but I couldn't track down the bug to fix it myself. So...

I then went hunting to see if this was a known problem that I could fix in some other way. Of course not knowing how the followers widget works internally didn't help. Anyway after a lot of false starts I eventually found that adding the following JavaScript to the page just before the followers widget fixed the problem (it really does have to be just before the followers widget or it doesn't seem to help, I added it, inside script tags, at the end of the archives widget to get it in the right place):

window.JSON = {
    parse: function(st) {
        return st.evalJSON();
    },

    stringify: function(obj) {
        return Object.toJSON(obj);
    }
};

Apparently the problem stems from a bug in prototype that messes up the JSON parser used by the followers widget.

So if you find your followers widget disappears after adding a new widget or some JavaScript to your layout it might be worth seeing if this fixes the problem before you spend two days trying to hunt down the solution.

Simple QuickTime Movie Embedding

QuickTime has a very useful "Export for Web" feature that can produce a number of different versions of the same movie targeted at different devices. As well as the different versions of the exported movie it produces a web page with instructions and an example of how to embed the movie in your own website. This is a great but, as far as I am concerned, the way Apple have chosen to embed QuickTime movies in web pages has a number of drawbacks:

• The markup needed to embed a single movie is quite extensive, requiring a JavaScript function call and a noscript tag to manually embed a player when JavaScript is disabled.
  
• Their solution uses two rather large JavaScript files and a style sheet. These files are not ridiculously large but they seem very over engineered for solving what is in essence a very simple problem.
• The appearance of the embedded movie when JavaScript is disabled is different, most notably no clue is given that it is in fact a movie which can be played by clicking upon it.
• There is no simple way of customizing the way in which the movie is embedded in the web page.

So I've put together a solution which attempts to address all of these issues making it both easier to embed QuickTime movies into pages within your website as well as giving you more control over their appearance.

I've put together a demo page with a number of examples, but to give you an idea of what you can do, how about the option to watch the trailer for Fracture or WALL-E.

Updated 26/10/2008: I've added a check to see if QuickTime is installed so that we don't even try to embed it if it isn't there.

Updated 07/11/2008: I've removed code that worked around the Eolas patent as a) I don't think it is really needed and b) it was causing two instances of QuickTime to be embedded in IE which resulted in audio problems. Thanks to Jonathan for pointing out the IE problem.

Updated 27/11/2008: Added the ability to provide either a re-direct URL or a function to be called when the user clicks to play a movie if they don't have QuickTime installed.

Updated 30/11/2008: A very minor update to allow the URL of the QuickTime movie to contain parameters.

Updated 02/12/2008: Added the ability to place links to the QuickTime movies outside of the DIV in which they will be played. Thanks to Stephen for the suggestion.

Updated 14/10/2009: Updated the CSS styles to include the standard CCS3 opacity as new versions of Firefox no longer respect the -moz-opacity setting. Also the script now ensures that the DIV in which the movie will be played is fully within the viewable area by scrolling the page if necessary.

Updated 26/11/2010: Added support for showing alternative HTML content if QuickTime is not installed. Thanks to Niklas Olofsson for the suggestion.

if (window.opera && opera.wiiremote)

While my current readership maybe small (4 at last count) it is diverse. As such I'm sorry that some posts maybe of absolutely no interest to some. For example, today's post is probably relevant to only 1 of my readers!



Object detection is considered the best way of implementing cross browser JavaScript -- that is check to see which methods are available and then use the correct combination to achieve whatever it is you are trying to do.

Detecting the Opera web browser is easy as it's the only browser to implement the window.opera object. The Nintendo Wii console has an Opera web browser but until yesterday I had no idea how to recognise it as different to the PC version of Opera without looking at the user agent string, which can be easily spoofed.

It turns out, however, that Opera on the Wii has extra objects that allow access to details of the Wiimotes -- opera.wiiremote. So we can use this to detect when we are running JavaScript on the Wii by checking for window.opera && opera.wiiremote.

Of course we can do much more than just detect that we are running on the Wii. As far as I can tell the only thing that can't be detected are the values from the accelerometers. There are a number of demo pages as well as a simple game called Wii Roll that you can try.

Of course you can't develop web pages on the Wii so testing web pages will mean trekking backwards and forwards between your PC and the Wii. Of course someone else has already thought of this and developed a wiiremote emulator script so that you can develop and test on your PC.