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:
@rem since your last tweet (roughly 20 minutes) I bought a slice on Slicehost for 20$ and got the #nodejs example server running on it.
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:
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.
Git was simple, although I did go round the houses a little. Just run:
sudo apt-get install git-core
Now git was installed.
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
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:
]]>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:
]]>
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:
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).
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!
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:
]]>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.
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.
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
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 was a HUGE success. A few issues I hit were:
That was about it for problems. Pros included:
And few more nice thing tucked away in twitter, and lots of pictures have been uploaded to flickr too (under the #fullfrontal09 tag).
The conference was a success because of a number of factors, including:
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:
]]>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.
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:
]]>
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:
]]>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).
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
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 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>';
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:
]]>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.
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:
Check it out, bookmark it, make use of it:
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):
This can be combined as per the current search in to more complicated search strings: font OR cheese -wife.
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:
]]>

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.

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:
]]>
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
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:
]]>legend element simply doesn't work inside both details and figure, myself and others been keen to find a solution.
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.
I've gone through a number of alternatives with Jeremy and Bruce and I want to share them with you:
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
Update Bruce's tests so far show that label is working fine with screenreaders
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)
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, 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).
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.
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:
]]>The one result I'm seeing is what I'm now referring to as a vomit bug.
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:
]]>details element using JavaScript (apparently the same day as fellow Brightonian Jeremy Keith).
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.
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 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:
details element prove both difficult to interpret and difficult to implement.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.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.
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 (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 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.
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:

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.
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:
]]>So here's my fix: http://twitpicapi.appspot.com/
I've created an API that scrapes the data straight off the Twitpic site to get your images back out.
I've not gone so far as creating integration to Flickr (which actually where I want to put my images), mostly because that exists already.
The JSON API is easy to use, but I've had to limit it to one page at a time (because the backend processing takes too long).
http://twitpicapi.appspot.com/
Usage and examples are explained, but it's pretty self explanitary (and it supports JSONP too):
http://twitpicapi.appspot.com/rem?callback=mypics
The service will resolve to the original url of your image too, but annoyingly, the title/description isn't always present, since it depends on your client sending it along at the same time (TwitterFon does this, but Tweetie doesn't).
With any hacking I play around with, I've made the project open source, and all the code is available on GitHub here: http://github.com/remy/twitpic-json
Feel free to log issues, fork it and make it better.
In addition to GitHub lovelyness, this is my first Google App Engine project written in Python (which I've not written before).
I was a 2 hour hack project, the initial source of which came from Simon Willison's JSON-time project on GitHub, and then I hacked from there, occasionally checking out the manual
It wasn't too painful, though I definitely thought Python was more OO that my experience (though it's likely I screwed up!).
I'd like to move Twivatar across to App Engine at some point to reduce the load on my database, and I needed an excuse to play with Python, so this was an attempt to scratch an itch.
Related posts:
]]>
If you've not seen it already through Twitter or colleagues blogs, HTML 5 Doctor is a tutorial site that aims to take the pain out of learning the new whizz bang stuff that's going on in HTML 5.
I was brought on board as the last doctor - oh yes, that means I'm the David Tennant version
along with the following motley crew: Rich Clark, Bruce Lawson, Mike Robinson, Tom Leadbetter and Jack Osborne. No doubt my posts will primarily focused on the JavaScript APIs available in HTML 5 (and around - since lots of cool stuff has been separated out).
Go check it out, subscribe, follow and buy the t-shirt (...well, perhaps one day).
I'll be cross posting the introductions of these articles to my blog, and you'll be able to read the full article over at HTML 5 Doctor.
Similarly, I've decided I'm going to cross post the intros of these articles, so that you have the choice of reading the article or not. They're all jQuery related and go through tutorials in detail - they also all come with a screencast (for those of us who can't be bothered to read - i.e. me!).
I'm also working on the jQuery for Designers book, so I've gone a little quiet on the blogging front (or at least I think I have) - there's been some delays on both my side and the publishers side, but it's coming along now (though it's in the drag stage!).
I've had some cover designs so far, I can't say I'm over the moon, and the final design needs work on the font choice, but I guess that's something we'll sort out much later down the line (if at all). I guess if anything, I can call it the Black Book (ala Metallica's Black Album).
I'm doing more speaking this year, along with workshops which I'm excited and slightly nervous about. I'm trying to post up as much free information to the talks page as I can (i.e. PDF links without having to register with SlideShare).
The talks are swinging between jQuery and HTML5 (with a dash of unobtrusive experiments) - so if you can come along, great! Otherwise, check out the videos and the slides if you want.
As usual, I've been hacking away at other projects, and particularly focusing on HTML 5, so I'm working on a mini project called: HTML 5 Demos
The site will run along similar themes to Chrome Experiments, in that I want people to be able to submit their own HTML 5 demos to share some knowledge.
I've been posting a few demos up there already, so feel free to have a play and check out the source code.
Other projects I've hacked together recently (and may, or may not blog about in more detail):
Related posts:
]]>To hide my duplication, I've written wasted my time creating a simple plugin that gives me the ability to bind to more than one event at once.
Paul kindly pointed out that the functionality is native to jQuery - so here's the examples.
That'll teach me for writing code late at night! I completely overlooked that this is native functionality within jQuery: $('input').bind('keyup change', fn);
I'm leaving the post here, but have retracted the download link (and tweaked the post a bit).
This is where I would normally need the function twice. Here's the lame version of the code:
$('input').keyup(function () {
var i = 255-this.value, j = this.value;
$('body').css('background', 'rgb(' + [i,i,j].join(',') + ')');
}).change(function () {
var i = 255-this.value, j = this.value;
$('body').css('background', 'rgb(' + [i,i,j].join(',') + ')');
});
Which can be simplified to:
function colour() {
var i = 255-this.value, j = this.value;
$('body').css('background', 'rgb(' + [i,i,j].join(',') + ')');
}
$('input').keyup(colour).change(colour);
But the colour function feels redundant because it's only required for that little bit of closure (and sure, I know for high performance apps, it's probably better that way, but we're just hacking right now).
With multibinding, you can bind the same event handler to more than one event:
$('input').bind('keyup change', function () {
var i = 255-this.value, j = this.value;
$('body').css('background', 'rgb(' + [i,i,j].join(',') + ')');
});
Related posts:
]]>I pondered this for a few minutes, thinking it could be done using a bookmarklet and an overkill amount of JavaScript to inject a flash MP3 player of some sort. I promptly returned to my pint forgetting about the idea.
In a moment of bordem the idea returned to me this weekend, and then I remembered we now have the <audio> tag (actually we've had it for over 18 months).
Now the bookmarklet is no code at all!
Drag the bookmarklet up to your bookmark bar, and if the browser supports HTML5, then you can fire off a rimshot or 'wah-wah-wahh' next time you near something daft in the office!
2009-07-07 I've since updated the bookmarklet to load both .wav and .ogg with correct mime types (Google code was serving it as application/x-octstream (thing - you know what I mean) ), and I've switched around the order in which they're being served. Apparently Safari is quite good at just getting the audio just to work, whereas Firefox is a little more picky!
2009-07-06 Upon further testing, this works (for me) in Safari 4, but silently fails in Firefox 3.5 - which I'm investing and will post my findings
I'm running the sound files off of a Google code project, so if you want some other daft sound, ping me and we'll add it in (or if you have better sound files).
Related posts:
]]>That said, they've released functionality tucked away inside the search results page that I never knew existed. Full accessibility support.
I spotted this when I was preparing my slides for the Sweden Geek Meet talk: Blueprint for Unobtrusive Web Development.
When using FireVox the free screen reader extension for Firefox, Google's search results automatically detected the assistive device and changed the experience for me.
Below is a video demonstrating the experience:
I've not looked too deeply in to it yet, but as far as I understand, using the AxsJAX library, Google is able to detect assistive devices and respond accordingly.
Here's a list of what changed from the traditional experience:
All this happens without me having to tell Google that I'm using a screen reader.
I definitely want to see more of this in upcoming applications (note: from what I understand, this is also built in to Gmail, Reader and number of other apps).
Related posts:
]]>@font-face is definitely a huge string to the CSS author's bow, in fact, it's like a freekin' flamin' arrow, but watch out, Safari isn't very nice to slow connections.
I recently peaked my total broadband usage and as a slap me down, my ISP, Plusnet, put me on about a 6Kb connection. Which sucks. Web pages are slow, email is slow: it's slow.
Anyway, I'm doing a talk at Standards.next this weekend on HTML 5 JavaScript APIs (slides will be available here too if you can't make it), and upon visiting the site in Safari - I got to see pretty much a blank page.
This was the sequence of events I saw in Safari as the browser downloaded the @font-face fonts:

I've run the same test against Opera 10b and Firefox 3.5b and both render the text out, and only once the font has been downloaded, do they then re-render the text, here's Opera (I also captured Firefox, but the heading is clearer in Opera for this example):

I'm not sure if that first screen is the FOUC bug - I didn't think it was...
The real issue for me, is the simple fact the text is missing. It's not that unique that I'm on a slow connection. It's slow when I'm using my 3G dongle. It's slow when my laptop is tethered to my iPhone. The more we use mobile telephony to do wireless connectivity, the more we're going to see slow download speeds (certainly for the next few years). We need to keep in mind those slow connections are out there as real users, and not just some family farm in the middle of The States somewhere.
Oh, and Webkit should fix that bug!
Related posts:
]]>Twitter avatars is one of those annoyances. If you've built an app that caches a Twitter user's avatar, and that user changes their avatar (@joshr is a good example of this), the link breaks, thus breaking your app.
I've spoken to Doug Williams about this (during the Devnest in April) and there's a split argument over at Twitter: some say there should be an API, some say to re-poll Twitter to get the latest avatar.
This weekend I decided that I'd had enough, and decided to hack together a fix myself (affectionately known as a toilet project for those who know me).
I give you: Twivatar (twivatar.org)
Twivatar is a RESTful API that lets you specify a Twitter username and it will return the avatar.
Usage
<img src="http://twivatar.org/[screen_name]" />
Alternatively you can specify the size image you want from:
<img src="http://twivatar.org/[screen_name]/[size]" />
I've also got the app whitelisted so there's no worries about it being blocked from Twitter.
All the source code is available on GitHub so go ahead and fork 'n hack if you want to.
You can see the API working in action on the Weird Habit site - yes, it is safe for work
Related posts:
]]>