bookmark_borderThe Trouble with CSS Transitions

Recently in a little experiment, I made a rather cool demo which makes use of CSS Transforms, combined with CSS Transitions.

Note: Examples only work in Safari 4+, or other recent webkit-based browsers.

Footprint Demo

“Cool?” you say. Well admittedly I could have gone for something a bit more elaborate, however as it stands it pretty much serves its purpose – that is to demonstrate that using the magic of CSS Transitions you can create fast, useful web effects which run at acceptable framerates on an iPhone, and even on the desktop (since the tweening of properties is done by the browser).

However to get this admittedly simple demo working, I had to battle through a few odd issues with how these transitions operate.

The problems

To start off, resetting transitions is a bit tricky. Since properties are not processed immediately, you need to wait for the browser to detect you have reset transition values before you transition to any new values.

Thankfully a nice event called webkitTransitionEnd is provided which is fired as soon as a transition is complete, so you could conceivably use it to handle resetting the transition.

The only problem? webkitTransitionEnd seems to only fire when it feels like it.

Circles Demo

The above example demonstrates the peculiarity of webkitTransitionEnd. The green/pink circle is meant to change colour every time the event is fired. Since there is an interval running every 100ms which changes the rotation of the circles, what typically happens 99.9% of the time is the transition never really ends, thus no event.

In general, the transition event seems to behave as follows:

Setting… Result
Initial transition (element just created) FAIL
Transition continuously (during transition) MOSTLY FAIL
Transition after a sufficient undefined delay PASS

So safe to say, unless you’ve got a transition you aren’t going to mess about with then don’t rely on webkitTransitionEnd.

Onto quirky platforms…

Finally, with regard to the iPhone platform there are even more quirks. Compared to desktop Safari, the tweening acts quite differently.

One notable quirk is if you make a new element with a transition on Desktop safari, it performs that transition. If however you do the same thing on Mobile Safari, the transition starts at the end. Whether or not this is some bizarre timing issue, I have no idea.

So safe to say, while CSS Transitions are a powerful tool to use, beware of the quirks.

bookmark_borderDisplaying Image Hints on an iPhone

Recently it has come to my attention that there is no way to view hints on images on an iPhone.

Normally on any modern desktop web browser when you hover your mouse cursor over an image, a hint if provided will be displayed. Certain websites use these hints to comedic effect, and it’s a shame you can’t see them.

Fortunately I have come up with a nice and simple bookmarklet to solve this issue. Simply add it to your bookmarks in Safari, sync over to your iPhone and run the bookmarklet.

Simply genius!

To view a hint, simply hold down two fingers over an image. The associated hint will be displayed in a pop-up alert.

The bookmarklet is as follows:


Or you can check out the full code in this gist.

bookmark_borderA Browser within a Browser: HtmlCanvas

It’s been a while since my last truly silly project, so I thought i’d come up with something else.

There has been a lot of talk recently about how the web is essentially replacing desktop applications, which to me sounds great.

But there is something missing from this new age of web applications. In order to run web apps you need a web browser, which is still a desktop app. It seems to me odd that a platform which replaces another still requires that platform to operate.

Which is where htmlcanvas comes in. It’s a HTML renderer implemented in JavaScript, which runs nicely in any capable web browser which supports the Canvas) element.

htmlcanvas in action

In essence, it’s a web browser implemented within a web browser. The above example was rendered from this HTML:

<body><!-- Begin test -->
  <p class="woo" id="render">
Rendering <b>HTML</b>...</p>
  <p><span>In <b>Canvas</b></span>!</p>

This sort of recursive abstraction is not uncommon in the computing world. For example, C compilers are written in C, Pascal compilers are written in Pascal. There’s even a version of Python implemented within Python. So a web platform implemented within a web platform is quite natural.

Still, it will be a long while before htmlcanvas is remotely capable of running within itself, so a truly recursive web browsing experience is still a long way off.

As with most of my silly projects, the code to htmlcanvas is hosted on github. Fork it here!

Note:: Currently only known to work in Safari 4, FireFox 3.5, or Google Chrome.

bookmark_borderThe Mystery of Jekyll

I recently stumbled across the much-loved Jekyll, a “blog aware” website generator.

I say “blog aware” since I have yet to be convinced it is. Jekyll seems to work fine if you have a flat layout of _posts with topics, but as soon as you stray away from that, it begins to fall apart.

An Example

I’ll give you a real world example. This blog. Simply enough, i’ve got posts organised into categories. I’ve also got a few tags on the posts, though they are mainly intended for the website feed. After reading the Jekyll documentation, it says:

Categories are derived from the directory structure above the _posts directory. For example, a post at /work/code/_posts/2008-12-24-closures.textile would have this field set to [‘work’, ‘code’].”

So I think “_right, i’ll make folders for my existing categories then stick their posts into each respective posts folder”.


This actually works rather well: if I list {{ site.posts }} from /index.html, each post gets listed with their .categories attribute set.


However if I list a posts .categories in the actual post, the list is mysteriously empty. It’s like Jekyll decided to make the categories act as some weird reverse breadcrumb system. Why this would be remotely useful, I have no idea.

The problem with how posts are listed gets further compounded when you start to use topics. All of my real blog posts are tagged “blog”, so in order to list them I actually use This works fine, until I try and list posts from within a “category”.

For some bizarre reason, the list of posts varies depending on which category you list from. For example, I have a /feed folder which contains an rss feed template. The only posts listed in the feed are those in my “dev” topic.

My only guess is that since alphabetically “d” comes before “f”, Jekyll is going through each category one-by-one and making posts on-the-fly. Pre-processing? We don’t need pre-processing!

The only real solution seems to be to store all of your posts in the top-level _posts folder, but that sort of defeats the purpose of using a folder-based category system.

Onto pagination and beyond!

Now assuming you have got your posts sorted out, you’ll probably want to paginate them, right? Well good luck with that; while Jekyll will allow you to split posts up into pages, the paginator is a global option. So if you want pages, you’ve got to have pages on everything.

Got multiple lists of posts on a single page? Well watch out, you could be in for a nasty surprise!

Which brings me onto the rather limited Liquid markup Jekyll uses. Now I don’t have much of an issue with the Liquid markup itself, after all I thought it was used rather well in Mephisto.

But in Jekyll, i’m constantly trying to find a workaround for its rather limited set of liquid tags. Want to list posts by date? How about multiple tags? Good luck with that!

So safe to say, unless you have a pretty simple blog with a flat layout then out-of-the-box Jekyll quite simply doesn’t cut it yet – sad but true.