Help make JavaScript documentation better!

JavaScript is awesome. I think we can all agree on that (or you’re reading the wrong blog, I suppose). The state of JavaScript documentation? Is not so great. Besides that we need a concerted effort to create better documentation resources and tutorials for programmers new to the language, the top hits for search terms like “JavaScript documentation” or “JavaScript tutorial” are all pointing at spammy SEO-optimized websites.

The JavaScript community is taking action now to solve this—please help us by:

1. Join Promote JS! and put up one of their generated-just-for-you banners up on your blog (best in the sidebar or footer!).
This will help getting valuable links for popular JavaScript-related search terms higher up in Google’s results, so that newbies use the Mozilla documentation and not one of the spammy websites.

2. Write posts! Articles about introductory JavaScript topics are in hot demand! Want some extra hits on your blog? High-quality articles about JavaScript are a good way to go and will help the JavaScript community as a whole!

Today’s newbies are the ones that will take over from us JavaScript gurus in the future! Let’s make it as easy as possible for them to actually learn the language and contribute!

Zepto.js, a minimalist JavaScript framework for mobile WebKit browsers

Mobile WebKit based browsers (like those on the iPhone/iPad, Android and Palm webOS) provide really powerful DOM, JavaScript and CSS features. So why not use them in a framework, that’s specifically crafted for these modern mobile devices?

The ultimate goal really is to have a ~2k library that handles most basic dredge work for you in a nice API so you can concentrate on getting stuff done.

Say hello to Zepto.js! (grab the raw code).

Zepto.js supports jQuery-like syntax and API(including chaining) so if you used/seen that before, it’s easy to get started:

$('some CSS selector').append('<li>a new li element</li>')
  .live('touchstart', function(){ alert(this.innerHTML) });

$.getJSON('/some/service.json', function(obj){ /* do stuff */ });

Supported are basic operations like html, append, prepend, css, event delegation with live, transform-based animations with anim and ajax calls (get, post, getJSON). And all of this, thanks to WebKit’s rich features, in just 52 lines of code.

It weighs in at just half a kilobyte when minified and gzipped.

Because it’s so small, it’s easy to just stick it in a script tag directly. Of course, it’s certainly not complete yet, but what’s there already works quite nicely.

I’d love if you let me know about your ideas and feature requests about this! Please tweet @zeptojs or email me. And please go ahead and fork as much as you can on GitHub!

Go forth and use proprietary browser features

Here’s why you shouldn’t be afraid to use proprietary browser features–especially with stuff that’s more experimental and explorative in nature:

First of all, lots of good things come from once-proprietary features. My favorite example perhaps is the .innerHTML property of DOM elements, that originated on Internet Explorer. This property is not only easier to use than (just stick any HTML string in), but also much faster than classic DOM manipulation. Now all browsers support this, no big surprise there.

Useful features will be carried over into the “browser mainstream”, and are standardized retroactively.

Almost all features available in modern browsers came from a browser vendor to scratch a specific itch, be it CSS Transitions, client-side storage and databases, extensions to the DOM such as CSS Selectors, 2D drawing surfaces, vector graphics, and so on and so forth. The list continues endlessly.

Early adopting of new features you find useful is a good way to see them broadly implemented.

Of course, some proprietary features won’t make it, or only in vastly different form (Google Gears come to mind). But mind you, it’s not that hard to adopt once things change. Client-side storage is client-side storage after all. APIs might also change (mostly in subtle ways) when they make the transition from proprietary to widely-adopted. If you do use these, you’ll probably have to check from time to time if everything works as expected on the latest browser version (if you’re serious about web development, you’re probably doing that anyway, as new browser versions can break existing, well-working code by introducing new bugs).

Most of the time, there are ways to cope with backwards-compatibility in case you need it, by falling back to other technologies (for example, a lack of WebSockets support might be worked around by using Flash). But, don’t concentrate on the problems, think about all the awesomeness you can create. Solutions to problems can always be found.

Participate on open-source wrapper libraries that are useful to more people than just you.

A great way to cope with this issue is to use libraries that wrap the proprietary APIs and can react to changes to the underlying APIs, or even use different underlying frameworks depending on the browser (for example, Raphaël uses either SVG or VML, transparently), and as a team, you can do so much more.

By developing a popular library you might even be asked to participate in the future development or standardization of the feature and contribute your experience with it.

Always watch out for new developments!

There’s always something going on. It pays to check out beta verions and nightly builds of browsers, and try out some of the wonderful features that are coming up (check out WebGL, for example!).

Don’t be shy, and don’t let yourself be told “But! You can’t do that! It’s against the Web-Gods will! No committee approved that!”

With that said, go ahead and create the next amazing thing!

So, what’s the status of hardware acceleration, really?

It seems that Google Chrome is getting all the developer luv these days, but there are some facts that people get confused.

Here’s the deal: Google Chrome uses Apple’s WebKit HTML/CSS rendering engine that powers Safari. Google is not the creator of Webkit, Apple is.* What Chrome does is basically adding two components to the mix, Chrome’s user interface and a replacement JavaScript engine (V8, also used by node.js).

But, there are some parts of the Webkit engine that are either proprietary or are not easily ported to operating systems other than Mac OS X (or iOS). First and foremost among those parts is Safari’s ability to hardware-accelerate the compositing of web pages, including 3D CSS transformations.

These transformations and the added speed of the compositing are not available in Google Chrome (but they are on the way by means of a reimplementation). Neither are they available on Android.

Actually, regardless of what Google states in its design document about GPU accelerated compositing in Chrome (a good read otherwise, but they say hardware-acceleration is only available on Safari for Mac), there are several browsers “in the wild” that do support hardware-accelerated compositing (including 3D CSS), some of them cross-platform:

• Safari 5 for the Mac
• Safari 5 for Windows
• Mobile Safari on iOS (for a long time now!)
• Nokia’s Starlight on Windows (a proof-of-concept browser)

Here is the blurb from Safari’s features page:

Safari supports hardware acceleration on Mac and PC. With hardware acceleration, Safari can tap into graphics processing units to display computing-intensive graphics and animations, so standards like HTML5 and CSS3 can deliver rich, interactive media smoothly in the browser. Safari on Snow Leopard has improved hardware acceleration for plug-ins.

Tweet-sized conclusion: Hardware acceleration in (non-beta) browsers is only available on Safari (all platforms). There’s no hardware-accceleration (yet) for Chrome (or for Android).

(Other browsers will add support for hard-acceleration too, but it seems that all will be Windows-only for now, with both Firefox 4 and Internet Explorer 9 only supporting that platform.)

*WebKit was orginally created as a fork of the KTHML rendering engine. While the main development effort is done by Apple, patches come in from a lot of sources, and companies like Nokia, Google, RIM and Palm are all contributing, mainly to support their specific branches and platforms. Some of the ideas found in Google Chrome, namely the sandboxing of individual tabs, will make their way into WebKit2, a refactoring and reimplementation that is currently underway.

Creating awesome CSS3 animations

Yarrrr!! Meet Captain Track, the awesome animated CSS3 pirate!

First, grab a WebKit-based browser, like Safari (preferably, because it supports hardware-acceleration!) or Google Chrome and head over to timebemoney.com and say “yarrrr!” to Captain Track!

Note that on the iPad and iPhone, these animations run with a full, super-smooth 60 frames per second, because of all the hardware-accelerated glory in Mobile Safari.

The best thing is that all this glory will eventually come to all browsers, so don’t get left behind and start using this awesomeness now.

Here’s the whole animation dissected:

Arm & Map

The arm & map image is a transparent 24-bit PNG (note the translucent brownish shadow).

This image is absolutely positioned, and rotated around a point on the left border of the image, a bit down from the center, so it appears that the arm is rotated around the elbow of Captain Track.

@-webkit-keyframes arm {
  from { -webkit-transform: rotate(0deg); }
  70% { -webkit-transform: rotate(9.7deg); }
  to { -webkit-transform: rotate(0deg); }
}

#arm {
  position:absolute;
  left:360px;
  bottom:0;
  width:246px;
  height:210px;
  background:url(img/arm.png);

  -webkit-transform-origin:0% 60%;
  -webkit-animation:arm 3.9s ease-in-out infinite alternate;
}

As far as special CSS3 animation tricksery goes, the -webkit-transform-origin property can be used to set the point around which to rotate in the animation.

The animation itself is defined through the use of the @-webkit-keyframes keyword. This defines an animation by providing several keyframe definitions, that specify which CSS properties should be applied at which points in time during the animation.

The magic happens through the -webkit-animation property that will take a keyframe definition with several options and then smoothly animate the frames between the keyframes, so that in this example with the rotating arm the rotation is smoothly interpolated from 0 degrees to 9.7 degrees.

The -webkit-animation property takes several arguments:

• Name of the animation’s keyframes definition (“arm”)
• Duration of the animation (3.9 seconds)
• Easing setting (“ease-in-out”). This is set to ease in and out so it looks better with the “alternate” animation style, where the animation goes back and forth
• Iteration count setting (“infinite”)
• Direction setting (“alternate”) – the animation “rocks back and forth” between 0% and 100% of the keyframes definition

As for the specific values to use–please do experiment! The only way to get good-looking animations is to practice making them and trying to tweak settings all over the place. Of utmost importance is perhaps the duration of the animation, followed by tweaks to the keyframe timing. For example, I used a 70% keyframe so that the durations of moving the arm from 0% to 70% and from 70% to 100% differ slightly, which makes the the back-and-forth rocking more appealing (this works really great together with the “alternate” setting).

While rotating, part of the arm is masked out with a simple positioned DIV with a black background, so that only the map part of the image overlaps into the central white background area.

Clock handles

The clock face is animated by using two copies of the same clock handle image, layered on top of each other. Again, 24-bit transparent PNGs are used:

@-webkit-keyframes pointer {
  from { -webkit-transform: rotate(0deg) scaleY(1); }
  25% { -webkit-transform: rotate(-90deg) scaleY(0.9); }
  50% { -webkit-transform: rotate(-180deg) scaleY(1); }
  75% { -webkit-transform: rotate(-270deg) scaleY(0.8); }
  to { -webkit-transform: rotate(-360deg) scaleY(1); }
}

#pointer1 {
  position:absolute;
  left:257px;
  top:177px;
  width:9px;
  height:23px;
  background:url(img/pointer1.png);

  -webkit-transform-origin:5.5px 18px;
  -webkit-animation:pointer 4s linear infinite;

  -moz-transform-origin:5.5px 18px;
  -moz-transform:rotate(55deg);
  -o-transform-origin:5.5px 18px;
  -o-transform:rotate(55deg);
}

#pointer2 {
  position:absolute;
  left:257px;
  top:177px;
  width:9px;
  height:23px;
  background:url(img/pointer1.png);

  -webkit-transform-origin:5.5px 18px;
  -webkit-animation:pointer 9s linear infinite;

  -moz-transform-origin:5.5px 18px;
  -moz-transform:rotate(-45deg);
  -o-transform-origin:5.5px 18px;
  -o-transform:rotate(-45deg);
}

The interesting part here is that the clock face isn’t really a circle but an ellipse, so I’m scaling the handles down horizontally a tiny bit with scaleY so it all fits in there.

The -moz-transform and -o-transform properties will make the clock handles show up in nicer default positions on Firefox and Opera (hope those browsers will support CSS3 animations soon!).

Eye (blink!)

The Eye is perhaps the most surprising element of the animation because it’s actually using none of the amazing new features, but rather uses a buzzword of the mid-90s: animated GIFs. Yes, you read right. Animated GIFs are widely supported across browsers and a relatively easy to create with tools like Photoshop.

First, here’s the eye in all it’s glory. Just wait for a bit and you will see it blink very briefly!

To create this in Photoshop, just have two layers, one with the eye open, and one with the eye closed, and then use the “Animation” palette to create a timeline-based animation (the darker areas show when the layers are shown). Save with “Save for Web & Devices…” and you’re all done!

This can be used for more complex animations, like the “map path” that shows up further down on the page.

Yarrr! Don’t forget, Captain Track loves to help you free-lance more efficiently!

Want to know more? Learn even more at my HTML5 Mobile Pro Workshop (next one is on October 5, 2010).