Midori, a lightweight browser using Gtk+ and WebKit.

Every passing week, Gecko feels more and more like old news. I love having options, though, so I hope they catch up.

Via reddit.

Many months ago, I worked on a MYSTlore feature called Palapeli. Why the name? Well, I needed an obscure word as a codename because generic terms are boring, and it appears palapeli is the suomi (Finnish) word for jigsaw puzzles. And, jigsaw puzzles is what the feature was to be about. You take an image from MYSTlore’s database (it has plenty) either at random, or chosen from a category (say, only images from Riven), or picked in particular, and then have the server generate puzzle tiles for you.

But, alas, my skills weren’t quite up to it, at least not within reasonable time constraints. Splitting an image into a grid of tiles isn’t hard; doing so with “interlocking and tessellating”, as Wikipedia calls it, makes for much more of a challenge (to me, anyway). Delivering the tiles to the client isn’t hard; implementing drag and drop and verifying that the pieces really are meant to fit together is another matter.

So I dropped the thing for a while and put my respective OmniFocus¹ project on hold, but never really gave up.

Today, I made significant progress – but not with my own project. Rather, I found a decent pre-existing jigsaw puzzle implementation that, like Palapeli, uses JavaScript on the client end, and PHP server-side. Its demo page convinced me that this was more than good enough for a start.

This isn’t quite as sophisticated (yet) as Palapeli would have been. For example, as you can see from my project screenshot, I was going to have randomized tile sizes (for higher skill levels). What’s also lacking is a means of fetching the images straight from MYSTlore using either the MediaWiki API or a custom way of accessing the images (possibly directly by their file names; they’re not stored in the database).

But for now, I’m sufficiently pleased with it to launch it like this. So go ahead and fool around with it. Here’s the docs, here’s the puzzle (refresh to get a different image), and here’s the variant you perhaps didn’t want to see.

1. Yes, I’m one of the lucky alpha testers. ↩

Sounds too good to be true, but it is. No ETA, but now we do know it’s coming.

Simply awesome. After the recent additions downloadable fonts support for TrueType through @font-face and client-side database storage, WebKit now sports another feature other engines don’t have at this point.

Building upon CSS working group drafts for the rotation property, -webkit-transform goes beyond that by adjoining support for scaling, translating, skewing and affine transformations.

Denis built a nice test page (compare to the original, where a similar effect is done manually) that uses rotation and a box shadow. You’d need a recent nightly to see the effect.

As noted, “At the moment transforms do not affect layout”, so the bottom rotated image slightly ‘eats into’ some of the text. Other than that, it looks great, and is something I can see myself using on my future design, albeit it in a far more subtle, less distracting way.

Cool.

No support for H.264 though, I assume. Sad that Google won’t open that up (does Apple have some exclusive deal with them on it? if so, that’s silly).

Also, ironic that users of the Apple TV and iPhone get an arguably better YouTube (although more limited in functionality) experience than Mac users. 10.5 Leopard’s Front Row (which is virtually identical with that of the Apple TV) will somewhat remedy this, but I don’t really want to use Front Row to watch a YouTube video either. For me, YouTube-style content is best enjoyed on the side.

Perhaps there’s a chance some project like NicePlayer or Miro will step up. And maybe, just maybe, there’s even a chance Google will give us poor Germans download rates beyond 10-15 kByte/sec.