How the launch image works on PhoneGap

Basically there's two launch images. Once for the native app and once (manually by PhoneGap) whilst the UIWebView (aka Safari) is loading up. The native one is handled by the app as per the documentation on the Apple developer site, but the overlaid image is hardcoded to 'Default.png'. This is what we'll fix.

Changes to PhoneGapDelete.m

To get the three devices to work properly, you need to make a change to PhoneGapDelete.m. Changing the following line^†:

UIImage* image = [[UIImage alloc] initWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Default" ofType:@"png"]];
imageView = [[UIImageView alloc] initWithImage:image];
[image release];

To:

UIImage *image = [UIImage imageNamed:"Default"];
imageView = [[UIImageView alloc] initWithImage:image];
// [image release]

† Note that I've not learnt Objective-c, I've just messed around and Googled enough to get to this point!

imageNamed

The reason we switch from initWithContentsOfFile to imageNamed is for two reasons:

1. initWithContentsOfFile is also using the bespoke pathForResource which returns the full path to the file, which we don't want as I'll explain.
2. initWithContentsOfFile apparently doesn't correctly pick up the @2x resources for the iPhone 4 retina displays

Adding the Launch Images

Now you need to create three images, for:

1. iPhone 3GS and below
2. iPad
3. iPhone 4 double resolution

The details of the resolutions are available Apple's developer reference.

The iPhone 4 image is easy, you call it Default@2x.png and drag it in to the xcode project. The iPhone 3GS (and below) image is called Default.png and also dragged in to the project (there will probably already be a phonegap default image that you'll overwrite). Finally the iPad image needs to be called Default~ipad.png.

This only works because we've made the change to use initWithImage because it'll automatically detect the device type and add the extension.

One Final Tip

If you notice that when your app loads the launch image jumps, it's because the phonegap UIWebView is (incorrectly) offset by negative 20 pixels - we can fix this too.

Michael Brooks wrote a really elegant little bit of code that fixes the offset in the web view that's also contributing to the launch image jumping.

Add the code from this gist http://gist.github.com/510407 to your *AppDelegate.m (in that if your app is called jsconsole, add the code to jsconsoleAppDelegate.m).

Once that code is in, you'll have your universal phonegap app with launch images all in the appropriate size for the app.

I used this technique for the iOS version of JS Console (though I'm not totally sure it'll get accepted to the itunes store!!!).

Finally, if you want to learn more about PhoneGap, my conference Full Frontal, is running a full day workshop with Brian LeRoux entirely on PhoneGap, so check it out!

Related posts:

1. Doing it right: skipping the iPhone url bar
2. Poor man's JavaScript Behaviours

New Google Calendar icon most un-Googley. I like it.

Then Danny pitched in with:

I see Google Calendar has a new icon. They could use the current date rather than "31" though

So let's fix that shall we?

How it's done

The trick here is to use a canvas element and export the image data as a png. Since favicons can be pngs then we know this can work. Note that this technique has been done before.

The setup is needing to create two calendar images: one with the date if this doesn't work (defaulting to something like 31) and the second without the date text. For whatever reason, I went and replicated the Google Calendar icon in Photoshop:

The plan now is to use the favicon template and lay the text over. Simple.

The minimum starting point

Start your document by including the favicon link element in the head:

<link id="favicon" rel="icon" type="image/png" href="ical-icon-complete.png" />

The "complete" version is the favicon with the 31 on it already. Next we'll use JavaScript to dynamically create the favicon.

Using a canvas for dynamic favicons

We need the following items to make this effect work:

1. A canvas that doesn't have to live in the DOM, that's 16x16 - our favicon size
2. The template favicon image
3. Once, and only once, the template image has loaded, we then go adding the text
4. The date in a two character format, i.e. 04 is the 4th

That's it. For connivence I've added an id to the link element so that I can just change the href when the image is ready. The following JavaScript can be included anywhere below the link element:

(function () {
var canvas = document.createElement('canvas'),
    ctx,
    img = document.createElement('img'),
    link = document.getElementById('favicon').cloneNode(true),
    day = (new Date).getDate() + '';

if (canvas.getContext) {
  canvas.height = canvas.width = 16; // set the size
  ctx = canvas.getContext('2d');
  img.onload = function () { // once the image has loaded
    ctx.drawImage(this, 0, 0);
    ctx.font = 'bold 10px "helvetica", sans-serif';
    ctx.fillStyle = '#F0EEDD';
    if (day.length == 1) day = '0' + day;
    ctx.fillText(day, 2, 12);
    link.href = canvas.toDataURL('image/png');
    document.body.appendChild(link);
  };
  img.src = 'ical-icon.png';
}

})();

The important part is the order in which the code runs. It creates an image element, and hooks an onload event handler. When this onload event runs, it draws the image on to the canvas using ctx.drawImage(this, 0, 0). this refers to the image the onload event acted upon, and 0, 0 is the top, left position to start drawing.

Next we style the text and draw it on.

Finally using canvas.toDataURL we set a new href to the link.

You should be able to see the code running on this blog post, if you look at the favicon associated with this page, it should be the calendar icon with the correct date if your browser supports the canvas API (IE8 and below don't, all other browsers do).

Try changing the date to test it out.

Related posts:

1. How to detect when an external library has loaded
2. Performance profiling JavaScript
3. Rimshot with HTML5

Below are two screenshots from the mobile view of Full Frontal, my JavaScript conference:

Making the iPhone hide the url bar is fairly simple, you need run the following JavaScript:

window.scrollTo(0, 1);

However there's the question of when? You have to do this once the height is correct so that the iPhone can scroll to the first pixel of the document, otherwise it will try, then the height will load forcing the url bar back in to view.

You could wait until the images have loaded and the window.onload event fires, but this doesn't always work, if everything is cached, the event fires too early and the scrollTo never has a chance to jump. Here's an example using window.onload: http://jsbin.com/edifu4/4/

I personally use a timer for 1 second - which is enough time on a mobile device while you wait to render, but long enough that it doesn't fire too early:

setTimeout(function () {
  window.scrollTo(0, 1);
}, 1000);

However, you only want this to setup if it's an iPhone (or just mobile) browser, so a sneaky sniff (I don't generally encourage this, but I'm comfortable with this to prevent "normal" desktop browsers from jumping one pixel):

/mobile/i.test(navigator.userAgent) && setTimeout(function () {
  window.scrollTo(0, 1);
}, 1000);

The very last part of this, and this is the part that seems to be missing from some examples I've seen around the web is this: if the user specifically linked to a url fragment, i.e. the url has a hash on it, you don't want to jump. So if I navigate to http://full-frontal.org/tickets#dayconf - I want the browser to scroll naturally to the element whose id is dayconf, and not jump to the top using scrollTo(0, 1):

/mobile/i.test(navigator.userAgent) && !location.hash && setTimeout(function () {
  window.scrollTo(0, 1);
}, 1000);​

Try this out on an iPhone (or simulator) http://jsbin.com/edifu4/10 and you'll see it will only scroll when you've landed on the page without a url fragment.

Related posts:

1. Fixing IE overflow problem
2. How to add Twitter to your blog, without it hanging your site
3. How to detect when an external library has loaded

So with a bit of magic JavaScript making use of the ever useful closure JavaScript offers, we can create a simple method to handle this for us:

function throttle(fn, delay) {
  var timer = null;
  return function () {
    var context = this, args = arguments;
    clearTimeout(timer);
    timer = setTimeout(function () {
      fn.apply(context, args);
    }, delay);
  };
}

So if you were doing something with jQuery, like a key press validation, you would do this instead:

$('input.username').keypress(throttle(function (event) {
  // do the Ajax request
}, 250));

The keyword this is the input as you would expect, and all the correct arguments are passed to the event handle, i.e. it works the exact same way as you'd expect, except it only fires once the keypress event is idle for 250ms (in this particular case).

Related posts:

1. Ajax validation pattern
2. Stop treating Ajax as something special
3. jQuery Tag Suggestion

The way @replies work, is that if you start your tweet with @user only that user and your common followers (ie. that follow both you and me) will see the tweet.

If you want everyone to see the tweet, yet the tweet is in reply to @user, then you can you can hack the @reply system by putting a character before the tweet.

Instead of doing:

@brucel and I are doing are talking HTML5 at London Geeknights

I'll insert a period character (it can be anything you want) and it'll be seen by everyone:

.@brucel and I are doing are talking HTML5 at London Geeknights

When would you want to use this?

I only use this when my reply is of value to all my followers.

If it's not, and only a specific reply, then I don't hack the @reply.

Inverting the hack, not CC'ing lots of people

The inverse of this hack (perhaps...!) is when you're having a conversation with a specific group of followers. You don't need to /cc them all if you all follow each other. For example, if I'm replying to a tweet from @codepo8:

@brucel @adactio HTML5 has wings! (not a real tweet!)

I can reply with simply:

@codepo8 Like redbull or something else?

And since @brucel & @adactio follow @codepo8 I know they'll see the reply too in their main stream.

If I want to force it in to their replies, then I'll include them in the @reply if it's really worth getting to their attention.

Related posts:

1. A better Twitter search
2. Twitter script upgrades & JSONP hacking
3. Tweet offline & better locations

How do you know if the plugin is good to use?

It's always dependant on the problem they're trying to solve, but in lieu of a better jQuery plugin ranking system, here's a couple of tips that should raise a red flag.

Consider the following:

$.fn.myplugin = function () {
  var me = $(this).each(function() {
    return $(this).bind('someEvent', function () {
      // does something
    });
  });

  return me;
};

Although the code may be perfect once some event has run, most times you don't have time to read through all the code carefully and you need to make a decision so you can move on to the actual problem you're trying to solve.

In the code above, there's a number of red flags that have gone up for me, and I tend to look in this area of code first. If these patterns have been used, it tells me the author hasn't quite grasped how jQuery works and hasn't considered making simple tuning changes.

The inline return

$.fn.myplugin = function () {
  var me = $(this).each(fn);
  return me;
};

Should be written as:

$.fn.myplugin = function () {
  return $(this).each(fn);
};

The me variable isn't being used again, so there's no point in creating it.

Double jQuery

$.fn.myplugin = function () {
  return $(this).each(fn);
};

Whilst within the context of the plugin code - i.e. within the function attached to .fn, the keyword this refers to the jQuery instance, not DOM elements.

If I were to rewrite this to show you the value, you'd see:

$.fn.myplugin = function () {
  return $($('div.foo')).each(fn);
};

So within the actual plugin (not jQuery callbacks), this refers to jQuery, so we can access jQuery's methods directly:

$.fn.myplugin = function () {
  return this.each(fn);
};

Returning what to each?

$.fn.myplugin = function () {
  return this.each(function () {
    return $(this).bind('someEvent', fn);
  });
};

jQuery's each iterator simply loops, it doesn't collect anything. The result variable is jQuery with the original collection inside it still - you can't modify the collection by returning or not returning.

So return isn't required at all in this case:

$.fn.myplugin = function () {
  return this.each(function () {
    $(this).bind('someEvent', fn);
  });
};

Wasteful use of each

$.fn.myplugin = function () {
  return this.each(function () {
    $(this).bind('someEvent', fn);
  });
};

Hopefully by removing all the cruft from the starting version, this next step should be obvious. If not, here's a clue:

• What's returned from an each call? A jQuery collection.
• What's returned from a bind call? A jQuery collection.

Since we're running the bind on each element, and only doing that, it means there's no difference. So let's throw away the each call and just return the bind:

$.fn.myplugin = function () {
  return this.bind('someEvent', fn);
};

Remember that within the plugin, this refers to the jQuery instance, and not the element, so we don't need the wrapping $().

All better now, eh?

Related posts:

1. jQuery multibinding events
2. Element 'in view' Event Plugin
3. jQuery tutorial: Text box hints

Related posts:

1. Firebug 1.0 beta
2. Firebug in IE for *any* web site

I should add before I continue, that it's not difficult by any measure if you know what you're doing (which I was about 80% of the way there myself) as per:

Slicehost

I did try out Rackspace Cloud at $11/month to start off with, but after the registration was complete they told me that they needed to call me to finalise verification. I wasn't at home so I didn't get the call. Plus, since I've moved my bank account is in a weird flux at the moment. Suffice to say, the account was never completed and I couldn't get access to the server. So I cancelled quickly and looked at registering with Slicehost.

Slicehost registration was a breeze - I started with the smallest option. One form to complete and the server was up. Amazingly easy. They had preselected an "Ubuntu 8.04.2 LTS (hardy)" distro for me, which if I was asked to select one of the distros myself, I'd have no idea which would be a decent starting point otherwise: 8, 9, 10? Who knows, I just wanted to get going. Perfect.

Immediately my server was running. I did hit one security block which you're unlikely to also hit because I was registering from the UK, but accessing from Switzerland (since I was still on holiday), but the customer support notified me of the security issue (which blocked my server) and literally had it all sort and resolved within 10 minutes. I whole heartily praise their support for the speed and personal touch they had sorting this out.

So, getting set up. I'd need the following:

1. My own account, rather than root
2. Git (so I could clone the repos)
3. Node.js (and thus also c++ compilers, etc)
4. WebSocket server

Configuring the Ubuntu server

Slicehost has a superb wiki with instructions here:

Getting Started With Your New Ubuntu Slice

I followed the directions up to the "pimping out your prompt" (since I've got my own poison). That was the user config done and now I could sudo and root was blocked.

Installing Git

Git was simple, although I did go round the houses a little. Just run:

sudo apt-get install git-core

Now git was installed.

Installing Compilers & Node.js

Getting node was simple as all I needed to do was clone the repo:

git clone git://github.com/ry/node.git

The problem was actually building Node - I hadn't installed the compilers, c++, cc, gcc, etc. Using a combination of hit and miss and shotgun approach, this was also simple:

sudo aptitude install build-essential -y

This gave me all the compilers, so I was then able to build.

I'm now going to fast forward through my experience and rather than take you round the houses, just tell you that you want the stable build and not the latest. The WebSockets don't work properly with the latest 0.1.28 build, and the stable build is on 0.1.26. So you need to switch branches (from the node directory):

git checkout origin/stable

Now you're ready to build. It actually took me a lot of faffing around to work out I wasn't on the stable release, so consider this a favour! Now we're ready to build:

./configure
make
sudo make install

Next stop, let's get the WebSocket server running

WebSocket Server

I personally wanted to play with the streaming Twitter API, conveniently there's a git repo for that!

I created a web directory in my home directory so that I could run my experiments out of, from there I run:

git clone git://github.com/andregoncalves/twitter-nodejs-websocket.git

From there I kicked off the server (by default it listens for "iphone"):

cd twitter-nodejs-websocket
node server.js <username> <password>

Now on my other "normal" server (though the smoothness of slicehost, I'm now thinking of porting across all my sites) hosts a simple web page (from the example in the git repo) that streams the latest tweets found by the server and should be viewed on a WebSocket enabled browser, i.e. Google Chrome (dev channel) or Webkit nightly: http://rem.im/relay-tweets.html (note that I'll be running this demo for a while, but it may well be taken down in the future). Here's a screenshot in case I've shut it down and moved on:

The core code to run the socket is simply this:

ws = new WebSocket("ws://<host>:8080/");

ws.onmessage = function(event) { 
  var data = JSON.parse(event.data);
  var $p = $(twitterlib.render(data)); // uses Twitterlib.js
  if ($('#tweets > li').length > 15) {
    $('#tweets >li:last').slideDown(100, function () {
      $(this).remove();
    });
  }

  $('#tweets').prepend($p);
  $p.slideDown(140);
};

ws.onclose = function() {
  alert("socket closed");
};

No doubt I'll be posting an article on HTML5 Doctor about WebSockets and writing about it in the upcoming Introducing HTML5 that I'm writing with Bruce Lawson.

Related posts:

1. LAMP in Leopard OSX 10.5 (PHP5 and Apache 2.2)

Stephen Shankland, writer for CNET News got in touch and asked me to comment on an article he was writing, posing me the questions in this post. Unfortunately my reply got to him to late and he had to go to post without my answers, but I thought that it would be worthwhile sharing my views via my own blog instead.

How far is HTML (and SVG and CSS and WebGL and JavaScript) to reproducing what Flash can do today?

HTML, SVG, CSS and JavaScript are very far along to replacing a lot of what I see Flash doing today - but it should be noted my browsing style is general usage, rather than gaming or interactive videos - which Flash is good at.

WebGL is very much at an early stage in it's development, only really (currently) appearing in the nightly builds of Webkit and Firefox, equally I've seen videos from Mozilla putting WebGL on to a Nokia device with no optimisation and it being able to render pretty well.

There's lots of examples of apps and effects that have been achieve using Flash in the first decade of this century, but today we can build these using Open Web technologies. This ranges from the simple image galleries to full fledged word processors. Adobe released Buzzword which relies on Flash, but on the other side we have Google Docs which relies entirely on the Open Web.

Would you like to see Flash replaced by HTML?

I personally don't think HTML will replace Flash. I think HTML5 and the Open Web will replace Flash where Flash has been used as a stopgap. sIFR is used to bring "custom" fonts to the browser, but now we have really good support for native custom fonts via the CSS fonts module, and products like TypeKit and FontDeck are making it easy for web authors to include those custom fonts without the need of Flash.

The native video element will (eventually) allow us to drop using Flash for video. Flash has done an awesome job of pulling the braces up on browsers for the last decade, and we've needed it, but Flash is so much more than just video or font rendering. I think the smart developers aren't won't be worried about native browser functionality making Flash redundant for noddy tasks, no doubt they'll be thankful to not have to build another video player.

As much as I'd like to see Open Web technology do everything, I still think we're a long way off HTML being able to able to natively replace applications such as Aviary and games like Bow Street Runner.

Equally, as I mentioned before SVG is one technology that has come along, and with the help of the svgweb JavaScript library, SVG works in IE. This library of course gets IE to support SVG via Flash. It translate the SVG markup on to a Flash canvas proving that Flash still has a place on the web as a bridging technology as well as it's intended use.

How serious do you think the H.264/Ogg Theora matter is with the HTML5 video codec?

It's hard to say. Personally it doesn't make much difference to me if I have to encode once, twice or three times. Encoding is a background task so I set my converter off when I produce my screencasts and after an arbitrary amount of time I'll have some files to upload - obviously if you have masses of video to encode the disk usage is going to be a possible issue for you.

The problem lies with patents, which is why Firefox and Opera won't implement H.264 - but the politics and patents are for smarter people than me. There's also the fear that we as content producers could be liable for license costs to the patent owners of H.264.

On the other hand, the company that own the patent for H.264 has elected not to collect royalties until 2016 - when they may again choose not to collect royalties. Flash developers have been using H.264 for some time already and there hasn't been any retribution for them, but for now I'll be producing both H.264 and Ogg Theora encoded content.

I'll be watching this topic closely to see how browsers deal with the two codecs.

As HTML etc. gets what Flash has today, do you think Flash will move upstream and remain relevant, become optional, or what?

I think two things will happen. Firstly I do think that Flash will move (or remain in some cases) upstream, and continue to push what's capable within the browser. Gaming is a great example of an arena that Flash excels at. The second thing I think we'll see is Flash developers taking the progressive enhancement approach to applications, relying more on HTML based solutions and enhancing upwards using Flash - Jeffrey Zeldman posted a great article recently suggestion exactly that.

How difficult is it for a Web developer today to use the fragmented Open Web standards vs. the more consistent Flash?

I don't think it's too hard at at all, but it really depends on what technology you choose. Web Storage has pretty solid support in the latest browsers (if not the nightly builds), but it's relatively easy to patch missing support just using JavaScript which would map sessionStorage to the window.name hack and localStorage to cookies.

Geolocation can be detected and made use of if it's available, whilst those without the functionality can still map their position using something like Google Maps or a text field, thus taking a progressive enhancement approach.

Offline applications on the other hand can't be achieved if the technology isn't available - so it really depends on the application, it's use and whether you have a specific platform in mind for deployment (which generally I wouldn't encourage, but we know it happens).

Flash developers definitely have an easier time when it comes to deployment environment - in fact I've met a number of Flash developers now that said they made the shift from JavaScript and HTML years ago to Flash because of the appeal of a single environment: the Flash runtime.

Anything else on the subject?

As I said at the start of this post, I don't see this as an us and them, Open Web and Flash. I do see HTML5 plugging the areas that have been held up by Flash for the first decade of this century, and there are other areas that HTML5 supports that Flash doesn't - but Flash could even make use of, such as Offline Applications.

It's an exciting time on the web again where browsers are implementing features that make it an even more powerful platform to develop on. I for one, am keen as mustard to get building with the new shiny toys they're giving us. Equally, I'm certain Flash will continue to be used to build awesome shit (and probably some not so awesome shit) for a long time yet.

Related posts:

1. HTML5 spell death to Flash?
2. Safari 3.1 web developer functionality
3. html5 and Firefox2

Projects

Aside from client projects, I also like to tinker with technology and launch my own projects, here's a run down of some of my favourites:

• Full Frontal - our very own JavaScript conference, the idea stemming from a conversation during "snow day" in Feb 2009, where Julie and I sat in a pub and I complained that there should be a JavaScript conference. Come November we ran our own conference at the local indie cinema Duke of Yorks to my great pleasure it was a massive success. Pictures, my review, others: #1, #2, #3, #4, #5
• Snap Bird - out of frustration with the 10 day limit in Twitter's search, I decided to reverse engineer the search structure and apply it to individual timeline lines, which have a limit of 3,200 tweets - busting far out from the 10 day limit, and most of the time you're looking for something specific. It started out as a plain grey project and with a gentle tweet request for design and within a week Chris Bewick and (local) Paul Annett had given me an awesome logo/mascot (Chris) and design (Paul). I use this tool probably once every other day to find various lost tweets, one project I'm damn proud of.
• JS Bin redesign - with the help of UX local Danny Hope JS Bin is getting a long awaited make over, but also dynamic syntax highlighting and some tighter features, such as milestones. It's not live yet, but it's getting there, and I'm also making the project open source.
• HTML5 Doctor - I was kindly invited to join the HTML5 Doctors just before they launched offering a JavaScript perspective on HTML5 (though I've written a number of non-JS based articles already). A project that aims to translate the specs for web authors and organised by Rich Clark a great resource for those wanting to learn HTML5.
• HTML5 Demos - created out of the need to experiment with HTML5, I figured I may as well share those experiments.
• Twitter hacking - I've built a number of twitter related apps this year, in fact enough to run two demos during the 140 second presentations at Devnest (run approximately every two months). Including a permalink for twitter avatars, an app to find where your friends are located and bunch more

Personal

2009 was even bigger than this post can begin to explain for me personally, and a lot of my personal achievements have been in my working life (because I allow - purposely - the two to bleed into each other).

• Moved house - no less than 5 days after Full Frontal, Julie and I moved house, from our small one bed-flat, to a 3-bed house. A big jump, and we're definitely growing up! It's definitely a family home (though currently it's just us and the cats) and somewhere I can see us staying for a good number of years.
• Full Frontal - yeah, I'm repeating this one, it was freekin' huge for Julie and I to run a conference that sold out and was a huge success with it's delegates. I'm really looking forward to the challenge again next year.
• Meeting the locals - 2009 was the first year where I didn't have another job to support my business, so I had to start meeting people if I didn't want to spend a year working from my bedroom with only my cats for company (they're great, but not that great!). So I met people in Brighton, and (I'm partly blaming my Austin experience) I've made new friends I never expected to find - I consider my self a very lucky chap indeed to have met and befriended all the people I have done this year
• jQuery evangelist - I was invited to join the jQuery team as an evangelist, which mostly means continuing what I've been doing, but I'm proud as pudding to be officially representing the library.
• Publications - the jQuery Cookbook was published in November, I contributed chapter 7 - effects, I contributed a featured article on HTML5 to .net magazine along with a tutorial article a few quotes for jQuery winning the award for best open source app.

Travelling: personal & speaking

• March: Claviere, Italy - snowboarding, mine and Julie's first solid week of powder. Crazy that we've been snowboarding for 10 years, and only how we get a week of powder. It was awesome none the less!
• March: Austin, Texas - for SxSWi. Much to my surprise this experience actually changed me. I'm generally quite a shy chap, and Austin forced me to be more on my own than I had been in a long while. I created new friends, something that I've been traditionally very precious about, and now as a man in his 30s, I'm making new friends almost as much as when I was a kid at school.
• May: All over Peru - Julie and my big trip, 3 weeks out in Peru. We had an absolutely amazing time, walking 4 days to Machu Picchu was an experience of a lifetime. I can rarely express in words the experience, but if you ever have the chance, I'd recommend it in a heart beat.
• May: Stockholm, Sweden - invited to speak at SWDC arriving only one day after getting back from Peru, proved to be incredibly expensive as jet-lag cost me my return flight home None the less, it was great to meet Robert Nyman for the first time, Molly and Dylan again after SxSWi (Dylan saved me with coffee, video adapter testing and Dr Who - so über kudos) and meeting Jan and Malte (who I would meet again for jsconf.eu) and organiser and scandie tasmanian devil: Peter Svensson.
• June: Stockholm, Sweden - only to return 2 weeks later to speak with Chris Mills to talk at Robert Nyman's Geek Meet. 150 odd people and one of the bigger talks I had given so far, and the feedback was really good (possibly because our talk was to be 2 hours and slightly laden with beer!).
• August: Leamington, UK - invited to talk HTML5 at the Geek in the Park and really nice day up north (I'm from Brighton, everything is north for me!)
• August: Zürich, Switzerland - for a friend's 30th birthday, where I got to see quite possible one of the best signage I've seen.
• October: London & Cambridge, UK - DevDays, talking about jQuery as an introduction to developers, but had the chance to speak to over 900 developers, and to my surprise it went down really well on the day (though criticisms in post reviews were it was aimed too much at the beginner - something I'd agree, and generally don't do), including great quotes like more accomplished presenters shone too, Remy Sharp was first rate!.
• October: Copenhagen, Denmark - I had some business travelling to do, and I wanted to take Julie along for some of the trip away, so we used Copenhagen as our base and travelled around. It was a pretty city, easy to walk around, but pretty expensive to what we were used to
• November: Malmö, Sweden - for Øredev speaking about jQuery. It was sadly a fleeting visit, but the conference was absolutely huge and the first I'd been to that put the food on for us - I didn't spend a penny!
• November: Berlin, Germany - again to speak, this time on HTML5 JavaScript APIs for JSConf.eu - which was crazy good. Two solid days of developers listening to JavaScript related talks, so much enthusiasm for language that had been given a bad wrap for many years. I strongly recommend the conference if you can get a ticket for next year.
• December: Lisbon, Portugal - again talking HTML5 JS APIs, but this time I had time to really hone the content compared to JSConf.eu, and ditched some content and replaced it with more detail, a talk that I think went really well, talking to over 300 people and (hopefully) getting them excited about JavaScript! It was a bit of a boys weekend too, I got to mee André Luís (an infinitely nice chap), Brian Suda (and talked about many a project idea), local Brightonian Glenn Jones, Robert Nyman (yep, again - this boy is following me, eh!) and Brian Leroux, (one of the) developer behind PhoneGap & XUI and hardened drinker as Julie and I would find out (Julie met me at the end of the conference so we could explore Lisbon some more).
• December: Bergen, Norway - more of a commute than a trip, but I got to visit Norway for a fleeting 48 hours while I gave an advanced jQuery and JavaScript workshop.

Then I got home and it was Christmas! Quite possibly the most travelling I've every done in a year, perhaps more than I had done up to that point in my life!

2010

I've got new challenges in the pipeline, some technical, some professional and some personal. For now, if you're still interested, I've started my own 365 project so let's see how I do on that.

Until the next post, thanks for reading, thanks for sticking with me and I hope your 2010 is going to be bees knees

Related posts:

1. The Long Ride
2. Presenting jQuery at QCon
3. Another day, another birthday

So over the next 10 months, Julie and I slowly plodded our way towards Friday 20th November where 248 (or so) developers and designers would come to our sunny city of Brighton for a day dedicated to JavaScript.

What started as a bit of complaining and wanted to scratch my own itch, ended up being an excellent day of talks and very, very well received first time conference.

Leading up to the idea

JavaScript is a passion for me. My hair stands on end when I talk about what can be done in this little language many have learned to love. I fell in love with JavaScript over 10 years ago when I realised I just needed a browser and notepad to code with. No compilers, no downloading tools, no SDKs. Just notepad and my imagination.

True, back then, my imagination was limited compared to today, but it's something that has kept me excited over a good number of years.

So when I found out that the US were running JS Conf, I knew I had to see something here in the UK.

JS Conf US turned out to be a massive success (well played Chris Williams, et al) which only cemented my feeling that the JavaScript community was (finally) coming together and there was a need for these conferences.

Once I had been convinced by Julie it was something we could do, I went about hand picking my speakers, and then announcing the conference. This also meant that there were no sponsored slots available, something I had been asked about after we launched, but I felt it was important to me to keep the content on topic and free of any sales pitches.

I was also adamant that the cost of the ticket should be cheap enough that I would be happy to go along. Sometimes you don't know how much you'll get out of a conference, so when faced with a £500 ticket price it's tough to justify, especially if you're a freelancer. I felt that around the £100 mark made it a much easier decision to make, freelancers and full timers alike.

Going from 90 to 250

Originally Julie and I had looked at, and were about to book, a venue in Brighton in a hotel convention room. It would hold about 80-90 people, was relatively posh, but still felt like it might come off as a meet up rather than a conference. This wasn't a big deal, but I wanted the day to feel special for the delegates along with delivering awesome talks.

However, a little over a week before the conference was set for 90 people, I had a conversation with Jeremy Keith changed all that. It went pretty much like this:

Jeremy: You should run Full Frontal at the Duke of Yorks cinema

He waves two fingers across my face whilst doing so, in an Obi Wan-esque way.

Me: you know what, I should run Full Frontal at the Dukes of Yorks

In my best "these aren't the droids we're looking for" face.

And that was that. We got on to the Duke of Yorks and suddenly our conference was increased by 150% - and the venue change was a superb suggestion, it added so much more character to the conference, and resulted in tweets such as:

At #fullfrontal09. Most comfy seats I've ever [known] at a conference — @jot

So thank you Jeremy

JS Conf.eu

Two weeks before Full Frontal, I had the honour of speaking at JS Conf.eu - which was an amazing conference. In fact, I highly recommend it for anyone wanting more JavaScript than you can throw a bunny at.

It was so good, that it actually started to really worry me that my own conference wouldn't live up to my own expectations, let alone the delegates (seriously, JS Conf was awesome).

The guys behind JS Conf.eu, Jan, Matle and hblank were all supportive of Full Frontal, and as I like to see in normal business, there was a collaboration of conferences rather than competition. My hat goes off to you chaps (and everyone who supported your conference).

The day

The day was a HUGE success. A few issues I hit were:

• The wifi was pretty nuked - but to be fair, that's the case at most conferences and I told all the delegates at the start of the day to use their 3G. My intention was that since most people would have mobile devices, they could tweet from there - and they did! I don't see this as big deal and I'm happy with how it was handled.
• I forgot music for the intervals, which only really showed in the morning when delegates were arriving, but by 9:10am I had hooked up my iPhone's music to the PA system, and the silence was broken. As it turns out, we didn't need it during the breaks.
• Lunch was a bit of a mad rush for the speakers. In fact, since we (the speakers and supporting staff) didn't get over to the local pub until (what seemed like) everyone else had, we didn't manage to get served before the 2nd half of the day resumed, so it was sandwiches all round. Not a biggie either.

That was about it for problems. Pros included:

• Hugely comfy seats and venue with great character
• Frickin' awesome talks from Christian, Robert, PPK, Stuart, Todd, Jake and Simon
• Jake's talk was not only pure comedy throughout, but riddled with genuinely good content, a balance that's hard to strike
• A successful after party (which I bought the first round for everyone)
• Everyone's really positive feedback to Julie and I after the conference and at the after party

And few more nice thing tucked away in twitter, and lots of pictures have been uploaded to flickr too (under the #fullfrontal09 tag).

Thank yous

The conference was a success because of a number of factors, including:

• It's sponsors: Yahoo! developer network, Guardian's open platform, Opera, .net, Dharmafly, O'Reilly and AVT.
• All of our delegates
• Our volunteers: Claire, Danny, Natalie and Jon
• Julie - my wife, who ran the strategic parts of the conference organising and the actual day itself, and kicked me up the bum to get Full Frontal to you all.

Full Frontal 2010?

Absolutely. I'll be releasing dates and a site as soon as possible. A Jeremy said, I'm going to have a hard job of matching this year's standard, but, hey, I'm up for a challenge if it means more awesome JavaScript talks!

Related posts:

1. Full Frontal JavaScript Conference
2. Going Full Frontal in one week
3. Win a ticket for the Full Frontal JavaScript Conference

It was turned on for early users and more of the "twittersphere" is getting the feature now. Certainly the first thing I wanted to see was what a native RT of 140 characters would look like. Well...truncated...but not really.

I posted this when I noticed native retweets were turned on:

I'm wondering: using the new retweet feature, what retweeting messages of 140 characters looks like to users that are not in the beta group.

So kindly, RellyAB (amongst others) retweeted for me.

Here's what it looks like with native retweets enabled:

...and here it is with out native retweets enabled:

Notice the ellipsis. No huge surprise there.

What's interesting is that the actual tweet is modified in the Twitter's view of the timeline, i.e. it's mashing together Relly's tweets and her retweets in to one view.

This can be seen in the new API method: home_timeline

Retweeting looks to be pitched as a thumbs up for a tweet, or "like" feature, but I personally agree with Cennydd when he said:

There's already a "like": Favourite. I think using that intelligently would have been wiser than the over-engineered RT.

But the upshot of this architecture change is that potentially the noise goes down. Since the retweets have their own API, the friends timeline can stay free (for now^†) of the extra noise. For example, in Tweetie, even though Relly had retweeted my experiment, it doesn't appear in her timeline:

Moreover, this is because the API call to user timeline is free of native retweets - so apps relying on it won't contain the retweet (for better or for worse - you may be using Snap Bird to find the tweet that was retweeted by Relly and fail to find it).

In fact, all of the native retweet APIs require authentication, so apps that rely on working without auth (such as Snap Bird) won't contain retweets at all in the future!

I'm not 100% sure whether this is good or bad, but it certainly mixes things up for the developers working with the API.

I think, if anything, it shows that Twitter are treating twitter.com as a client to the API, and (rightly) they're aggressively keeping up to date with API changes, and I think that other twitter apps are going to have to do the same.

Update

I've also spotted this (obvious now) functionality in Twitter - the ability to ignore retweets from particular users (via the green RT button on the right):

This is perfect for those people you follow and value their retweets, something you could have missed, and where you can choose to ignore others. Ignoring the developer implications for a moment, the user experience is definitely better, and this will pass down the chain to the third-party apps like Tweetie (once they update).

Obviously you'll still be able to bork the retweet feature by just adding it yourself, just like I can break the @mentions feature by adding a character (usually a period) in front of the @!

Related posts:

1. A better Twitter search
2. Twitpic API for getting pictures out

Full Frontal is really close to selling out, and I wanted to make a deal with you: if we sell out, Left Logic (my company, consisting of just me) promises to buy everyone a drink at the after party to kick off a great evening.

So if you're someone who's been thinking about coming along, or you know someone, this is the week to get your ticket.

The lineup consists of great topics by awesome speakers Christian Heilmann, Robert Nyman, PPK, Stuart Langridge, Todd Kloots, Jake Archibald and Simon Willison. The full schedule and abstracts are available on the web site: http://2009.full-frontal.org

Like I said, we're really close to selling out, so make your move now to get those last few tickets and the drinks are on me

Related posts:

1. Full Frontal JavaScript Conference
2. Full Frontal JavaScript 2009
3. Win a ticket for the Full Frontal JavaScript Conference

I've written a plugin which I'll share with you and also explain how it works (so you can add it to a non-WordPress site).

WordPress Plugin

The WordPress plugin has it's own control panel that you'll need to add your site's analytic's ID, something like UA-12345-6, save settings and you're off.

Download the noscript wordpress plugin

Reporting

All the stats on users without JavaScript will be stored under a page /noscript, the page the user was actually on will be the page referring to /noscript.

Doing it manually

Doing it manually is very simple. If you want to record where the user is coming from, then you'll want to grab this code, and replace the variables with your own values. I'd recommend either grabbing the plugin and whipping the code out of there, or copying the code below and making the changes for your own site.

$var_utmac = 'UA-12345-6'; // your identifier
$var_utmhn = 'http://mydomain.com'; //enter your domain
$var_referer = @$_SERVER['HTTP_REFERER']; //referer url

$var_utmp = '/noscript'; //this example adds a fake file request to the (fake) tracker directory

$var_utmn = rand(1000000000,9999999999); //random request number
$var_cookie = rand(10000000,99999999); //random cookie number
$var_random = rand(1000000000,2147483647); //number under 2147483647
$var_today = time(); //today
$var_uservar = '-'; //enter your own user defined variable

$urchinUrl = 'http://www.google-analytics.com/__utm.gif?utmwv=1&utmn='.$var_utmn.'&utmsr=-&utmsc=-&utmul=-&utmje=0&utmfl=-&utmdt=-&utmhn='.$var_utmhn.'&utmr='.$var_referer.'&utmp='.$var_utmp.'&utmac='.$var_utmac.'&utmcc=__utma%3D'.$var_cookie.'.'.$var_random.'.'.$var_today.'.'.$var_today.'.'.$var_today.'.2%3B%2B__utmb%3D'.$var_cookie.'%3B%2B__utmc%3D'.$var_cookie.'%3B%2B__utmz%3D'.$var_cookie.'.'.$var_today.'.2.2.utmccn%3D(direct)%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B__utmv%3D'.$var_cookie.'.'.$var_uservar.'%3B';

echo '<noscript><img src="' . $urchinUrl . '" /></noscript>';

Share

Then later, let's share the results and see what kind of sites actually have visitors with JavaScript disabled. That kind of information makes me more comfortable with things like the HTML5 shiv.

Related posts:

1. Download stats for S3
2. Last.fm Recent Album Artwork Plugin
3. Ajax validation pattern

That doesn't solve the problem of how am I supposed to find that tweet such and such posted a while ago.

So I've written two things: 1) a simple history search for user timelines and 2) a micro library for search filtering.

Searching Further Back

I've written a very simple, purely JavaScript based search limited to an individual's history or their favourites.

Currently you can't search your "friend" timeline, but it's a feature I'd be willing to add if people thought it would add a lot of value. If I did add it though, it would have to use Twitter's oAuth and I'd host it on a Google App Engine (or similar), firstly because friend timelines require authentication (although historically they didn't...annoyingly) and secondly, because I probably don't need to host another app myself!

There's also limits within the API calls I'm making, in particular:

1. User timeline searches are limited to 200 tweets per hit
2. Favourite searches are limited to 20 tweets (yeah, only 20!)

Check it out, bookmark it, make use of it:

http://snapbird.org/

Giving Back to Developers: Twitter Search Library

I figured search filtering is a pretty basic requirement, and it's one that I'd add to a lot of my own apps/hacks and one I'd like to see in apps being built.

I've put the search filter library up on Github for people to pinch, share, upgrade and do as you will.

http://github.com/remy/twitter-search-js

The library supports the following search commands (from the existing Twitter search):

• All these words. Example: cheese wine
• This exact phrase. Example: "good weather"
• Any of these words. Example: cheese OR @brucel
• None of these words. Example: cheese -wine
• From this person. Example: from:brucel
• To this person. Example: to:brucel

This can be combined as per the current search in to more complicated search strings: font OR cheese -wife.

Usage

Include the library and you can pass the raw tweet objects to the filter - that's the raw tweet and not the string (because it needs the tweet to assert the from this person).

if (twitterSearch.filter(tweet, searchString)) {
  // tweet passed search criteria
}

I'd love to see this library plugged in to widgets to allow live search filtering, or HTML based Twitter apps to apply dynamic search filters to any given result of tweets.

Related posts:

1. Hacking Twitter's reply system
2. Add Twitter to your blog (step-by-step)
3. Twitter Upgrades via Greasemonkey

dConstruct Workshop: jQuery for Designers

I ran the jQuery for Designers workshop at dConstruct this year and I was honoured to be able to contribute to one of the great conference in Brighton (of course there's more).

It ran from 10am until 5pm, overrunning by about 30 minutes. The night before I was worried I had too little content and was trying to work out what I would do if I ran 1-2 hours short. As it turned out, I had about 2 hours too much content, and 2/3rd of the way through, ditched the slides, the talky content, in favour for the remaining exercises. That way delegates could get more hands on experience and help directly from me as I'd walk through the solutions with them (either by their side or on the main screen).

There was lots of really positive feedback, and my handdrawn slides seemed to go down quite well. Although the talk was entitled jQuery for Designers, the vast majority of delegates knew some JavaScript (or jQuery) which meant the workshop was aimed a little higher than pure beginner. Equally I had a couple of friends who attended the workshop, with no experience tell me they struggled at the codey parts - so future workshops will be split between total beginner and intermediate - total beginner getting things like where to include the jQuery library, etc.

You can download the PDF slidedeck from the workshop and all the examples and solutions.

Barcamp Brighton

This was my first every Barcamp, and I had a really, really good time. The first day comprised of preparing my talk in the park with friends (because I'd been busy preparing for the jQuery workshop!), and then running to the venue and presenting.

I made the fatal marketing mistake of writing my talk in biro rather than marker pen, and choosing a title that had about 4 lines (only because I didn't know or have time to workout how to get a "great" title). Something along the lines of: "iPhone Apps, without the store, or Objective-C, using web technology and works offline!"!!!

My talk showed off the Rubik's cube I'd been playing with for the iPhone (and Webkit). It's not a full working game, but a proof of concept, check out the demo video to see what I mean.

The demo includes HTML5 offline applications, CSS 3D transforms (inspired directly by Paul Hayes' demo), iPhone web apps meta tags and a few other bits and bobs.

You can download the PDF slidedeck from the talks and all play with the live demo.

The organisers did an awesome job with the venue, food and drink, and I'm really looking forward to next Barcamp Brighton (I've almost convinced my wife to attend too!). I'm knackered from the last few days activities, but I've had some of the best laughs in a good while and have had my head stuffed with ideas over an incredibly short amount of time!

Related posts:

1. dConstruct 08
2. Updated jQuery Talk
3. Presenting jQuery at QCon

Free ticket or reimbursed ticket

I've never been sure whether to enter these competitions when I had already bought a ticket, so I figured I may as well make my competition the kind that I would enter.

If you've already got a ticket, and you win, we'll give you a full reimbursement. If you don't have a ticket, we'll give you one for free.

So, you can get your Full Frontal ticket now, and still enter

How to win a free ticket

We're drawing two winners for free tickets on Tuesday 1st September and Monday 2nd November, and announcing the winners via @fullfrontalconf.

Head over to the Full Frontal web site, and read the ticket draw details.

Pop the Full Frontal banner on your blog, and that's it. You can see an example of the banner on my sidebar to the right of my site.

If you have any questions, get in touch, otherwise: Good luck!

Related posts:

1. Full Frontal JavaScript Conference
2. Full Frontal JavaScript 2009
3. Going Full Frontal in one week

Ian Hickson has said:

I am leaning towards keeping the language sane (not introducing yet another element that basically means "header" or "important" or "caption"), at the cost of delaying how soon we can use the feature.

The huge problem with this is that browsers will not catch up. IE is the dominant browser, and if IE6 to IE8 don't support the legend element embedded in anything other than fieldset then we, as authors, are going to have to find an alternative. This is where the spec is fiction.

I agree with Hixie that a new element isn't required that means "header" or "caption", but equally I believe we have enough in the spec to label the figure and details elements properly.

Alternatives

I've gone through a number of alternatives with Jeremy and Bruce and I want to share them with you:

label

label: This was my initial favourite to work within the new elements, since what we're trying to do is label the figure or details that are tucked away.

The problem Jeremy raised was that of screenreaders. Are they going to look or assume there's an associated input element?

I'm not an expert on screenreaders, so I can't say for sure. Bruce suggests screenreaders may only look for the input element if the label is within a form. If this is so, then it's almost a good candidate.

My issue with this, is that it's perfectly reasonable, in my head, to have a figure within a form, which could cause screenreader problems.

Here's a label figure test: http://jsbin.com/elatu (edit)

Here's label in a details element and nested in a form: http://www.brucelawson.co.uk/tests/html5-details-label.html

caption

caption is used to add a caption to tables, which makes it a good candidate for captioning the figure and details elements.

However, due to a similar bug as the legend issue, if the browser finds the caption element outside a table, it simply strips it from the DOM - which makes this a non-option.

Example of caption being stripped from the DOM: http://jsbin.com/eloda (edit) (view the DOM and you'll see the element has gone)

Heading

Could we use an hX tag? We want to give the figure or details element a heading, so it stands to reason that we could use an h2 or h3, etc.

The problem is the TOC that's created.

I originally thought I could hide this from the TOC by using the hgroup, but this element will grab the first heading and include it in the TOC. So this isn't a viable solution because I don't believe these should be part of the TOC.

On top of which it seems over the top to include two elements just to solve this issue. I think the figure and details need a heading, and although using hX elements make sense to me, it feels klunky (for want of a more expressive technical term!).

Header

header, to me, has a similar semantic meaning as an hX element, and we could reuse this to replace the legend in the figure and details elements.

It wouldn't become part of the TOC, because you'd need an hX element to create a new item in the TOC. This also doesn't cause any issues with screenreaders (if in fact label does).

Here's an example of header being used in the wild (for the button example on the right): http://2009.full-frontal.org/ticket-draw

Lachy pointed out on the WHATWG IRC channel that in the future User Agents may treat the header element properly and using it for the caption to the figure or details would cause confusion to the browser (citation needed).

New Element

After discussing the issue on the IRC, aside from Hixie suggesting that the figure and details is dropped, one solution is to create a new element. This works fine in any browser because you're not stepping on an existing element. For example, using <c> as caption can solve the issue.

I don't mind how it's solved, obviously a c element would be duplicating the caption element, but that's unavoidable.

Conclusion

I think we need to discuss and find an alternative to hoping the browsers will fix the legend issue. figure and details are both useful elements, particularly the former, so I'd rather not see them binned from the spec. If label is viable, I think this is the best fit, otherwise (since header could cause long term issues), a new element can solve this.

HTML 5 paves the cowpaths but the use of legend isn't possible, so we must find an alternative if we want to sensibly uses this captioning feature.

I know using the html5.enable feature if Firefox 3.6b, but this still leaves all the other browsers (and Firefox 3.6 isn't even out) - so again, waiting to see what browsers do isn't a solution (nor is serving the page as XML - since IE just chokes).

What do you think? Is there a better alternative? How do screenreaders react to label?

Related posts:

1. Legend not such a legend anymore
2. html5 and Firefox2

The one result I'm seeing is what I'm now referring to as a vomit bug.

Definition

Vomit bug

When the browser's parser rearranges the DOM completely differently to the markup, resulting in content being placed outside its original container.

Examples

For example, due to a bug in Firefox 3.5.2 (and perhaps before) the following markup is subject to the vomit bug:

<a href="#">
  <section>
    <p>p nested in a section wrapped in a link</p>
  </section>
</a>

The resulting DOM is as such:

<a href="#">
  <section></section>
</a>
<p>
  <a href="#">p nested in a section wrapped in a link</a>
</p>
<a href="#"></a>

This is a particular bug in Firefox that triggers when it parses a section element nested inside an a element that causes all currently open element to close, and the contents of the section element has been "corrected" by the browser and the DOM rearranged.

Note that by using the html5.enable option in Minefield renders correctly.

You can see a live example here: http://jsbin.com/upiza

The old Gecko engine (for Camino and Firefox 2) suffers from the same vomit bug when introducing new (or HTML5) elements (which can be fixed by serving as XHTML).

What other vomit bugs have you found?

Related posts:

1. html5 and Firefox2
2. Legend not such a legend anymore
3. HTML5 enabling script

However I ran in to some very serious issues with the tag combined with the legend element, so serious, in it's current state, it's unusable.

This article has been cross posted from HTML 5 Doctor.

Overview of the details element

The details element, by default, is a collapsed element whose summary, or label, is the first child legend (if no legend is used, the UA provides a default, such as "Details"), with a triangular button to indicate it's current open state.

If you include the open attribute, then the element is open by default. In theory, you could attach a click event to the legend, and switch the open attribute.

The markup would roughly be this:

<details open="open">
  <legend>Terms & Conditions</legend>
  <p>You agree to xyz, etc.</p>
</details>

Here's the details test page I was working from: HTML 5 details test

The issues

The biggest problem, and the show stopper for me, is that the browser's treatment of the legend element completely breaks this markup pattern - this is true for all the major browsers: Opera, Safari, Firefox and IE (tested in all the latest and some older browsers). I'll go in these issues in detail in a moment.

Other problems include:

• Styling the legend element is exceptionally difficult, particularly positioning
• Using the WHATWG guidelines to styling the details element prove both difficult to interpret and difficult to implement.
• When using CSS to style the open state of the details element using: details[open] { height: auto; }, meant that once I changed the open state using JavaScript, it wouldn't trigger the browser to redraw (as it would if I had added a class). I've run in to this before, CSS 2.1 is styling source, not the DOM.

Legend treatment

Surprisingly Firefox is the worst one out in these issues, the rest of the browsers have fairly same treatment of the issue. In the screenshots, I've included a fieldset and nested legend for reference.

Internet Explorer

Both IE7 & IE8 closes the legend element it encounters when it's not inside a fieldset element and move it's contents out to an adjacent text node.

What's also strange, is that looking at the DOM it also creates another empty(?) closed legend element after that text node. It doesn't have any effect, but just looked odd:

Opera

Opera (9 & 10b) is very similar to IE in it's treatment of the legend in the details element, except it doesn't create the second closing legend node. It just closes the legend, and creates the adjacent text node.

Safari

Safari simply strips the legend all together out of the DOM. So much so, that if you open the web inspector, then the error console, you'll see it warning out that it's encountered an illegal element, ignoring it, then encountering the closing tag, so it ignores that too. You're left with just the text node.

Firefox

The best for last. Firefox goes one step beyond the other browsers. It assumes you've forgotten to include the fieldset element. So when it hits the legend element, Firefox inserts an opening fieldset up until it finds (I believe) the closing fieldset element, which obviously it doesn't so the result is the rest of the DOM, after the first illegally placed legend ends up eaten by fieldset element, which leaves my DOM in a mess:

Impact on other elements

details isn't the only element that reuses the legend element for labelling, the figure element also is supposed to support the legend element. The result is obviously going to be the same.

Conclusion

We can't style the legend element when the text is being thrown out by all the browsers, and Firefox's DOM mangling is just too painful to look at.

This basically means that we can't, in any reasonable amount of time, use the legend element inside both the details and figure element in the spec's current state.

For me, I'll be using an alternative element, probably just a p element styled to look like a legend, but that's really not the point. Ideas anyone?

It turns out we weren't the only ones looking at this and Ian Hickson has responded on the issue:

My plan here is to continue to wait for a while longer to see if the parsing issues can get ironed out (the HTML5 parser in Gecko for instance solves this problem for Firefox). If we really can't get past this, we'll have to introduce a new element, but I'm trying to avoid going there.

It's fine to think that Gecko will update, but it's IE that I'm worried about, they won't turn out their render engine, and the result is we'll have to avoid using the legend in any element other than fieldset.

Related posts:

1. Saving Figure & Detail
2. Safari's problem with @font-face
3. Firebug 1.0 beta