PastryKit, at least the one on the iPhone User Guide, contains (it’s possible their compiler strips out classes/functions their site doesn’t use)

• PKUtils – collection of util functions (eg. degreesToRadians, objectHasMethod, etc)
• PKClass, PKObject – classes that make inheritance easier. PKObjects to have observer methods for properties and PKClasses are able to synthetize properties ala ObjC.
• PKPoint, PKSize, PKImage – self explanatory OOO objects for points, sizes, and <img>
• PKAnimator – simple animator class taskrunner/setTimeout style. Even PastryKit doesn’t use WebKitAnimations since the API is fubar’d! As far as I can tell nothing in the framework or iPhone User Guide uses this
• PKTransition – This is where all the real animation is done, including the scroll effect, has the ability to commit animation transactions.
• PKView, PKContentView, PKRootView – View hierarchy, akin to one you would set up in Interface Builder. Very Xcode. I echo Gruber’s sentiments that PastryKit could show up in the next DashCode. Or at the very least the remnants of Apple’s web apps as an app strategy circa 2008.
• PKScrollIndicator – The magical class that creates the DHTML scrollbar when a view is scrolled.
• PKSearchBar, PKTableView, PKNavigationView, PKToolbar – the main view classes used to construct an actual app. (Along with PKScrollView, PKTableViewCell, PKNavigationItem, PKControl)

If you’ve built anything in Xcode all this seems very familiar. Applications are built by setting up a hierarchy of views such as:

// create a new navigation view
navigation = new PKNavigationView();
// set a size for the view
navigation.size = new PKSize(height, width);
// init some basic parameters about the view
 // add the view to the root view
PKRootView.sharedRoot.addSubview(navigation);
// build the rest of your views

I gave myself a couple hours to build a basic view app from scratch using PastryKit. It was painful and time consuming. There are plenty of methods that are required by the framework that you must declare unknowingly (eg. tableViewCellForRowAtPath vs tableViewCustomCellForRowAtPath dependent on what your table view is styled). Without proper documentation the framework is difficult to do any real work with. I’ll tinker with it some more but if you’re interested in a semi-prepackaged PastryKit and my work so far you can grab it here.

PKScrollIndicator is the best part of the framework, jQTouch should definitely look into “borrowing” this code. Meanwhile, I’ll be waiting for a documented official release of PastryKit.

Bonus: You can use the following to disable scrolling in Mobile Safari.

document.addEventListener('touchmove', function(e) {
  e.preventDefault();
}, true);

This coupled with window.scrollTo(0,0) is how PastryKit hides the navigation bar.

Update: Sorry, should be document.addEventListener() instead of window.addEventListener(). I’ve added a demo no scroll page here. Just view the source.

If you’ve downloaded Safari 4 Beta then you’ve seen a very cool welcome screen. If you haven’t seen it click the video above (or if you’re running Safari 4 you can view it again here). I was curious as to how this page was put together so I did some dissecting…

HTML 5 – Cleverly, Apple decided to use HTML5 and the <audio> and <video> tags for the sound effects and part of the animation. The only part that is a full blown .mov is the ending compass sequence. Here is the .mov.

CSS Animation – The first 2 animations, the Apple logo (plus lens flare) and the Welcome to Safari 4 are achieved by a combination of CSS animations (stylesheet) and a series of images.

The Welcome to Safari 4, is the simplest of the 2. It uses this image:

… and this scaling animation rule:

@-webkit-keyframes header {
	from {
		opacity: 0;
		-webkit-transform: scale(2.6);
		-webkit-animation-timing-function: linear;
	}
	20% {
		opacity: 1;
		-webkit-transform: scale(1);
		-webkit-animation-timing-function: linear;
	}
	77% {
		opacity: 1;
		-webkit-transform: scale(0.9);
		-webkit-animation-timing-function: linear;
	}
	to {
		opacity: 0;
		-webkit-transform: scale(0.1);
		-webkit-animation-timing-function: linear;
	}
}

The Apple logo animation is bit more tricky and is achieved with these four images:

… plus 4 different css animation rules that are similar to the rule above but each image’s opacity is changed from 0 to 1 at the appropriate time.

Works on an iPhone – What’s more impressive is that this page more or less works on an iPhone! The .mov and audio do not play, but everything animations properly. I removed the javascript that disables the page for non-Safari 4 browsers and put it here http://waynepan.com/s/safari4.

Bonus! – At the end of all the animation, the page redirects you to topsites://, which of course takes you to Top Sites.

The Safari Welcome screen is a peak into the future. It shows us what’s possible when you get to throw all backwards compatibility concerns out the window… (no pun intended.)

If you aren’t familiar with the new animation framework that’s built into Mobile Safari you can read about the closest thing on WebKit, CSS transitions. Here is an example of a CSS transition:

<div style="-webkit-transition: opacity 2s ease-in"
  onclick="this.style.opacity='0'">
This div will do a fade when clicked only Safari 3.1 or on the iPhone!
</div>

Essentially you tie a timing function and duration when a css property is changed. CSS animations allow for more complex rule transitions. For example, if you want to have a card flipping effect show in this video, you will need to use CSS animations.


CSS animations consist of a combination of 2 rules, one to define the animation timing, duration, and animation name. The second to define the actual animation.

/* the following rules make something shrink from 50px */
/* to 10px then grow to 100px in 2 seconds */
.shrink-n-grow {
  -webkit-animation-name: 'shrink-n-grow-animation';
  -webkit-animation-timing-function: ease-in-out;
  -webkit-animation-duration: 2s;
}

@-webkit-keyframes shrink-n-grow-animation {
  from {
    height: 50px;
  }
  50% {
    height: 10px;
  }
  to {
    height: 100px;
  }
}

There are a few issues with the Mobile Safari CSS animation implementation and I urge Mozilla, the IE team, Opera, and W3C to consider these before writing their own spec.

CSS means no syntax checking

Jonathan Snook wrote about this last year and until I actually started using them I didn’t feel the pain. Since all the rules are written in CSS there is no error checking. Figuring out that you’re animation is broken because you misspelled -webkit-transition: is painful enough. When you start working with perspectives for translateZ, it will drive you utterly insane.

Access through javascript problematic

Also, because the rules live in CSS world, modifying existing rules on the fly in javascript requires you to use this ridiculous function to scan through CSS rules and find the one you want and then modifying a value.

  var findAnimation = function(name) {
      var ret_rule = null, sheets = document.styleSheets;
      for(var i = sheets.length - 1; i >= 0 ; i--) {
        var sheet = sheets[i];
          for(var j = sheet.cssRules.length - 1; j >= 0; j--) {
            var rule = sheet.cssRules[j];
              // 7 means the keyframe rule
              if(rule.type === 7 && rule.name == name) {
                ret_rule = rule;
                break;
              }
            }
      }
      return ret_rule;
    }
  findAnimation('shrink-n-grow-animation').findRule(
     '50%').style.height = '25px'

Needlessly complicated

To use an animation, not only do you have to apply the final value of the animation if you want it to stick, but you have to perform some software olympics.

  // Add shrink-n-grow animation to a div
  var remove = function() { // we'll need this later
    // first, set final values
    theDiv.style.height = '100px';
    // then remove shrink-n-grow classname so that
    // it can be applied again animations are only
    // triggered when classnames are first applied
    theDiv.className = '';
    // remove this listener because webkitAnimationEnd
    // is triggered on every time ANY animation ends on theDiv
    theDiv.removeEventListener('webkitAnimationEnd', remove);
  };
  // listen for animation end
  theDiv.addEventListener('webkitAnimationEnd', remove);
  /// FINALLY, start the animation animation
  theDiv.className = 'shrink-n-grow';

That is just way too much code.

My personal preference is to have everything accessible in javascript so that the entire workflow of animation can live in javascript (instead of just modifying styles).