S5 with CSS Slide Transitions in WebKit

So, in an effort to have the ability to post my slides for my Zend/PHP Conference talk online without having to rely on Flash or typically awkward HTML exports from other formats, I've decided to go with S5, as mentioned previously. I've also decided to add a little of WebKit's recent additions of CSS transforms and animation support for transitions.

Since CSS CSS animation only occurs when attributes change, it just means that the current and next slides need to have the changes applied at different times, or at the same time, depending. To make managing these things easier, I started with a base object:

function Transition() { }
Transition.prototype = {
 "duration" : 1,
 "cslide" : null,
 "nslide" : null,
 "transition" : function(toggle) {
  this.cslide.style.WebkitTransition =
   this.nslide.style.WebkitTransition =
    (toggle
     ? 'all ' + this.duration + 's ease-in-out'
     : 'all 0s none');
 },
 "prepare" : function() { },
 "perform" : function() { },
 "cleanup" : function() { },
 "run" : function(cid, nid) {
  this.cslide = document.getElementById(cid);
  this.nslide = document.getElementById(nid);
  this.cslide.style.visibility = this.nslide.style.visibility = 'visible';
  this.transition(false);
  this.prepare();
  var dis = this;
  setTimeout(function() {
   dis.transition(true);
   setTimeout(function() { dis.perform.apply(dis); }, 0);
  }, 0);
  setTimeout(function() {
   dis.transition(false);
   dis.cslide.style.visibility = 'hidden';
   dis.cleanup.apply(dis);
  }, dis.duration * 1000);
 }
}

The code managing the switch of the slides now calls RunTransition(transitions[snum], cid, nid);, where transitions just holds an array of constructor references corresponding to the slide numbers (snum):

var transitions = [
 null,
 Fade,
 Wipe,
 Rotate,
 Rotate,
 Fade
]

function RunTransition(className, cid, nid) {
 var trans = new className();
 trans.run.call(trans, cid, nid);
}

Each transition just extends Transition and overrides the applicable methods in order to change the slide CSS properties at the correct time, like this Fade transition:

function Fade() { }
Fade.prototype = new Transition;
Fade.prototype.prepare = function() {
 this.cslide.style.opacity = '1';
 this.nslide.style.opacity = '0';
}
Fade.prototype.perform = function() {
 this.cslide.style.opacity = '0';
 this.nslide.style.opacity = '1';
}

I've uploaded a very quick demo of the transitions in action, which will work in whichever builds of WebKit support CSS transforms and animation. It worked a bit smoother in WebKit builds a few weeks ago than those current (bugs galore at the moment), but nightly builds always tend introduce unpredictable behavior.

Update (1/25): Between fixes in the WebKit trunk since this post, and fixes in my code (with many thanks to smfr in comments and on the bug itself), all of the transitions work in the current Webkit nightly! From my final note, just in case anyone else has issues with transforms when used with transformations:

"If you set the WebkitTransform using just matrix() in the first step, then set the WebkitTransition, then set the WebkitTransform using both matrix and scale, it (reasonably) will not apply the transformation. When I set both both functions for the start and end styles, it works beautifully."

Google launching open source browser based on WebKit?

No idea whether this theory holds any water, but given the recent speculation hitting...everywhere, I checked http://code.google.com/p/chrome/ and found a login screen (quickly followed by a permission denied error), rather than a Not Found error for a project that doesn't exist.

Wondering what this will bring to WebKit that Safari doesn't (aside from Gears and even-more-targeted advertising), but I guess we'll see soon enough.

Edited to add: the more I read about this, the more it looks like they ported a bunch of features from Opera (tabs above window chrome, long-running scripts' threads not killing your browser, Speed Dial-like default page, etc.) to a WebKit-based browser with what sounds like XUL for the window chrome itself. I guess tomorrow we'll find out for sure, but it seems a bit odd that an open source project would outright deny access to the public before launch, and distribute the info under the most closed-minded CC license available (feel free to share it, just don't touch it, don't charge for it, and you'd better tell people who made it). I suppose after the recent Android SDK excitement, this still makes a decent step forward, but still. I guess so long as it takes market share away from IE, I shouldn't complain too much.