The interface is fairly intuitive – just three panes for HTML, JavaScript, and CSS, and an output pane that displays your rendered content. It also has support for a number of JavaScript frameworks (jQuery, MooTools, etc), and a number of addons for those frameworks. It’s also setup as a collaborative tool – by default, your ‘Fiddles’ are public and accessible by URL. As a quick test of the tool, I ported the code I wrote for my ‘:between‘ jQuery selector – check out the demo here: http://jsfiddle.net/jneal/WmnNJ/.

You can even embed your Fiddles on other websites. Next time I write a post on a coding technique, I’m planning on setting up some examples through jsFiddle. Hopefully it turns out well!

There’s a new set of jQuery API documentation, with a new look and some other enhancements. One thing I’m a big fan of is the ability to see when a particular function was added to jQuery – it’s very easy to hone in on the new stuff that way. One thing I feel is still missing is the abilityto jump directly to the function implementation in the library, like how the Google Closure API documentation is setup.

Interestingly, the last day of the 14-days-of-jQuery-1.4 promotion will be the release of jQuery UI 1.8. jQuery UI 1.8 is looking to be a smaller release – a bunch of bugfixes and few somewhat underwhelming plugins, as well as support for jQuery 1.4. There are a ton of great jQuery UI widgets and enhancements that are in the proposal and development stages, but the pace of development has been very slow, which is disappointing. I’d very much like to see jQuery UI development kicked into high gear.

Overall, this is looking to be a great jQuery release. I’m impressed with the performance improvements (addClass is three times as fast now? amazing!), and the new functionality improves the experience dramatically. A lot of functionality that used to have to be gotten through plugins is now in the framework itself, which will be a boon to development. Check it out now!

Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

I think the new ‘live’ event handlers are going to be great. I can’t stress how much the ‘live’ method has helped my JavaScript development – it makes event binding much less of a chore when dynamically creating page content (especially for trivial things, like bindings for button hover behavior). One of the things I’ve disliked, though, is the change event of dropdowns isn’t able to be live captured, which has led me to use Live Query for those purposes. With 1.4, it can be done with jQuery alone.

It will certainly be interesting to see if the Lazy Load code is included, for on-the-fly .css and .js includes. By conditionally loading javascript and css, a lot of bandwidth could be conserved by choosing to defer file retrieval for little-used site features.

Some of the other cool new features will undoubtedly be radio classes and the offset get/set methods – I can see using those to save a few lines of code. I’m betting that there will also be some performance increases with 1.4, so I’m excited about the release, even if it’s release is still a few months off yet.

I’ve just released my latest plugin, the jQuery UI Image Carousel! The plugin is a standard-fare image carousel, and it’s also fully compatible with jQuery UI. It’s got a few options that make it fairly versatile – from a minimal look all the way to a collapsible version with a custom header.

The JavaScript itself wasn’t that daunting – version 1.0 clocks in at around 180 lines. Most of it is presentation management as well – making sure that the correct jQuery UI classes are applied to the markup, and so forth. In total, it was a bit of a longer exercise – there was a lot of work to insure compatibility with older versions of IE, for instance. I hope you enjoy, and if you use it, please take a sec to leave a comment with your page URL.

In other development, I’ve been trying to learn how to implement iPhone style gesture controls via JavaScript. I’ve been seriously spinning my wheels on this – my demo is turning out to be a dud, of sorts. It’s frustrating (especially the testing, which I can only do on my iPhone currently), but hopefully it comes together sooner or later.

Here’s a 3D CSS Animated Image Carousel that I created while I was learning about 3D CSS animation. Watch the video above to see the technique in action. If you’re on a 3D CSS animation capable browser (currently a non-production version of MAC Safari and mobile Safari in the iPhone and iPod Touch), go ahead and check it out. The video was shot with my XBOX360 webcam, of all things.

Here’s a GeoLocator example I put together that showcases two popular GeoLocation techniques – IP lookup and using the GeoLocation API – in order to both demonstrate the techniques as well as to show the issues with each.

In HTML, there are a few ways of determining the location of a user. Traditionally, this has always been accomplished by IP lookup – a lookup is performed with your IP against a database of known IP locations. This technique leaves a lot to be desired, but it’s been all that’s been available for a very long time.

In HTML5, however, there’s a new Geolocation API. The gist of this feature is that instead of relying on IP address lookup, the browser will instead interrogate the device for this information. This allows devices that have native geolocation hardware (GPS receivers and Wifi antennas, for example) to be able to pass their known location to the browser. Many web-enabled devices of today already provide support for this feature, including the iPhone, the Palm Pre, Android phones, and some netbooks.

The problem with all these methods, however, is that none of them just work on all devices. IP lookup works best in the workplace, but it doesn’t work as well for home users and doesn’t work at all for mobile users, as it pretty much requires a stationary device (amongst other things). The Geolocation API is not supported in all browsers yet (with the major notable holdout being all versions of Internet Explorer), and it tends not to work well on devices that don’t have built-in GPS capabilities (which the bulk of desktop and laptop devices still aren’t equipped with).

Worse yet, when location is returned via any technique, it is often inaccurate. In my case, IP lookup and Geolocation lookup provide locations that are over 10 miles away from each other! That’s not a discrepancy that can be resolved in many cases.

In the longer term, the Geolocation API is almost certainly the way to go. When it is fully supported, it is the most accurate method available. Today, though, the landscape is still fractured and implementing accurate geolocation is not trivial on the web.

I’ve created my first jQuery plugin this week – it’s an image overlay plugin (the static pic above doesn’t do the plugin justice, so click through to see it in action).

Creating a jQuery plugin isn’t that big a stretch for a competent JavaScript developer. There are quite a few tutorials out there where you can grab a template and start working very quickly. In addition to writing my plugin, I also made sure that it supported the metadata plugin, so that you can dynamically change properties on individual galleries and images, which should go a long way towards usefulness.

If you end up using this plugin, drop a line in the comments with a link so we can check out your work. Hope you enjoy!