In the old days, in order to make HTML look the way you wanted, you used more HTML. Every element had to be individually styled, using ribbons of FONT and CENTER and B tags. Then CSS came along and gave web developers the ability to group elements into classes with similar display characteristics. The world heaved a sigh of relief, and developers started making more complicated websites, confident that site styling would not get in the way of functionality.

Then JavaScript and AJAX became popular, and suddenly it became commonplace for elements to have their classes modified by JavaScript, based on the results of AJAX calls from the server. When an element’s class changes, it is updated instantaneously to reflect the styles associated with the new class. That’s fine for some stuff, but sometimes you want the transition between classes to be a bit more, um, classy. Let’s say your site has a login box that remains hidden on a page until a user clicks the “log in” link. If you switch the box’s style from opacity: 0; to opacity: 1;, it will appear right away by default. If you want it to fade in, you have to write a JavaScript function that increments the opacity bit by bit until it reaches 1, and you have to call that function at the same time as you change the class of the login box. If you have a bunch of login boxes on your site, you have to attach that transitional behavior to each one of them manually. Because CSS doesn’t have the concept of transitioning through time, animation-heavy websites are stuck in the same place that pre-CSS websites were before CSS came along.

CSS transitions solve this problem by bringing styles into the 4th dimension. CSS transitions allow web developers to specify that if an element has its style modified, the browser should smoothly transition its appearance to the new style, rather than shifting it abruptly. They’ve been available in WebKit for about two years now, and just appeared in Gecko a few weeks ago. Since they’re not available in most browsers, webOS developers are among the privileged few who can take advantage of them. Here’s how.

The Basics

Suppose your login box is 300px wide and you want it to hide offscreen until a user clicks a link, at which point it should get the class active and appear onscreen.

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px;
}
 
#loginbox.active {
  left: 10px;
}

Here’s a version of that with transitions:

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px;
  -webkit-transition-property: left;
  -webkit-transition-duration: .5s;
  -webkit-transition-timing-function: ease-in;
}
 
#loginbox.active {
  left: 10px;
}

And here’s how it’d look if you wanted the box to fade in and slide in at the same time:

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px
  opacity: 0;
  -webkit-transition-property: left opacity;
  -webkit-transition-duration: .5s .25s;
  -webkit-transition-timing-function: ease-in linear;
}
 
#loginbox.active {
  left: 10px;
  opacity: 1;
}

Here’s a brief overview of the three -webkit-transition properties used above;

-webkit-transition-property

A space-seperated list of the properties that should be animated when they change. You should only use numerical properties. “top”, “width”, “border-width” and “opacity” work, but “display”, “text-decoration” and “list-style-type”, for instance, do not. If this property is omitted, all the properties of an element will be animated. This is probably not what you want.

-webkit-transition-duration

A space-seperated list of the durations of the transitions of the different objects. “s” stands for seconds. This is 0s by default, so you need to set it.

-webkit-transition-timing-function

From the W3C Working Draft:

The ‘transition-timing-function’ property describes how the intermediate values used during a transition will be calculated. It allows for a transition to change speed over its duration.

“ease-in” starts slowly and picks up speed at the end. “linear” keeps the same speed all the way through.

And here are some things that aren’t supported in webOS (as of 1.2.1), but probably will be eventually, since they are part of WebKit 4:

-webkit-transition-delay

Allows you to set a delay before the start of the animation.

Events

Currently, there’s no way respond when a transition animation finishes, and this is the main drawback of the CSS approach to transitions. WebKit 4 lets objects listen for animation events, which will let you string a bunch of animations together without needing to call setTimeout() to activate each part of the animation.

In addition to the reduced code clutter, CSS transitions can speed up your app, since they are run from native compiled code, rather than from interpreted JavaScript. Don’t expect miracles, though — I’ve found that webOS can only handle a few animations at one time before things get choppy, and the size and complexity of the elements being animated also makes a difference. I was unable to animate a 320×480 image without choppiness. While there is no programmatic way to cancel the animations, they are smart enough to smoothly reverse themselves if an element’s properties change in the middle of a transition. If the active class is removed from our login box while it’s still sliding in, it will slide out starting from wherever it happens to be at the moment the class was removed.

For more on the basics of transitions, check out the W3C docs, and keep in mind that all the properties should be prefixed with -webkit- in webOS.

Advanced Tricks with -webkit-transform

There’s another advanced CSS property in webOS, called -webkit-transform, that, when combined with CSS transitions, allows for some neat stuff. -webkit-transform is…well, I think of it as a mini-CSS within CSS. It lets you apply transformations to an element after it’s been rendered. In webOS, The available transformations (to my knowledge) are translate, scale, rotate and skew. To scale an element to twice its height and rotate it 30 degress (something that’s been impossible in HTML until now!), do like this:

#myDiv {
  -webkit-transform: scale(2, 1) rotate(30deg);
}

The crucial difference between scaling a div with -webkit-transform and scaling by manipulating its width and height is that -webkit-transform will scale (or skew or rotate) the entire rendered div and its children smoothly. For more on -webkit-transform, see this post at Art of Web.

You can animate -webkit-transform by passing it to -webkit-transition-property. If you’re using a WebKit browser, hover over the card below to see an example.

#cardexample {
  -webkit-transition-property: -webkit-transform;
  -webkit-transition-duration: 1s;
  -webkit-transform: rotate(0deg) scale(1, 1);
}
 
#cardexample:hover {
  -webkit-transform: rotate(180deg) scale(1.5, 1.5);
}

Our games Word Ace and Card Ace use this technique for pretty much every animation in the game. It’s a lot of fun to describe the behavior of a class in CSS and have elements automatically move around when they’re changed. There were times when I’d forgotten that I had set transition properties on an element, and was surprised when it started moving around of its own accord.

Caveats

Advanced animations are tricky with CSS. For example, the timers in Word Ace and Card Ace use transitions. In order to start a timer countdown, the yellow timer bar gets two classes set: one to set the bar to “full”, and another that sets it to “empty” with a transition, so that the width of the bar decreases slowly. My first pass at the code was something like this:

// CSS
#timer-bar.full {
  height: 22px;
  background-color: yellow;
  -webkit-transition-property: width;
  -webkit-transition-duration: 10s;
  width: 100%;
}
 
#timer-bar.full.counting-down {
  width: 0%;
}

// JavaScript
function startTimer() {
  var timerBar = $('timer-bar');
  timerBar.addClassName('full');
  timerBar.addClassName('counting-down');
}

It didn’t work. The timer bar never went to “full”. After some research, I discovered a blog post explaining that changes to element styles are batched during an event, and are processed all at once after an event has finished, for performance reasons. In this case, WebKit sees that the classes I’m adding would set the element’s width twice, so it only bothers setting the second width — 0%. If you need to do a multi-step transition this way, you need to chunk the DOM manipulation into different events:

function startTimer() {
  var timerBar = $('timer-bar');
  timerBar.addClassName('full');
  setTimeout(function() {
    timerBar.addClassName('counting-down');
  }, 0);
}

Tricky, huh? This also applies in cases where you need to set a hidden element to display: block; before you move it around.

In Short…

CSS transitions make our games smoother, more lively, and easier to maintain. They’re not without their pitfalls, but once you master the basics, they’re an easy, elegant way to add a bit of zest to your UI. For more information (not all of which applies to webOS, unfortunately), see the Safari reference and the W3C working spec.

Dan Kurtz is the webOS developer at Self Aware Games, makers of Word Ace and Card Ace for the Pre and Pixi. Both are online multiplayer card games that make extensive use of the advanced JavaScript and CSS techniques available in webOS.

There were many concurrent sessions at the event today and I, being but one person, had to choose carefully.  It was difficult and sometimes I feel I chose… poorly.  However, the first meeting of the morning I chose to attend was Enabling Mobile for Business.  Charnsin Tulyasathien, Sprint Group Manager, started off the session, which included three Sprint partners.  He laid out the case for targeting business customers with mobile applications:  271 million mobile devices, 6.5 million mobile connected laptops, Bank of America’s mobile banking site has 1 million users.  Mobile is becoming a bigger part of business.

The first partner to speak during that session was Eric Kowalchyk of Intuit.  He outlined Intuit’s GoPayment system, which provides mobile payment processing.  He spoke about the iterative process they went through to get a payment system that served the needs of mobile professionals in a clear, easy to use manner.  He said:  “Focus on the end user to end user experience.”  Next up was Daniel Obodovski, director of business development at Qualcomm.  He talked about Qualcomm’s location tracking system.  He discussed some pretty interesting applications of location tracking devices.  They are targeting cargo tracking, asset tracking and consumer devices, such as the Best Buy child-tracking solution.  Following Daniel was Steve Hudson of Omnilink, a partner of Qualcomm.  He told us a story about how Delta had lost his luggage and he was able to track it down into a warehouse in Las Vegas.  One of the benefits of network-based LTS is that it doesn’t require visibility to Satellite, which is very useful for applications such as tracking Alzheimer’s patients.

Following those three partners Charnsin took the stage again to discuss the particulars of Sprint’s developer program.  If you are interested in the program visit their site:  http://developer.sprint.com or send e-mail to BAP@sprint.com.  The developer program is free to join for those interested in teaming and co-marketing.

After that session I attended the Alcatel-Lucent presentation on their Open API service platform.  Their API allows for some pretty comprehensive network-based services for mobile applications, including ‘geofencing‘.  One of he opening slides of the presentation discussed the fact that very few applications ever reach a very large user base.  The slide backed up the claim that there are very few iPhone App millionaires.  What Alcatel-Lucent hopes to provide is a framework that will allow app developers to create more compelling applications.  The services included the ability to detect users being online, opt-in tracking and more.  Check out their site above for details.  One thing to note is that although they are planning support for multiple carriers it seemed to be implied that they have not actually signed up other networks.  They demonstrated how a partner developed an opt-in advertising campaign for REI that sent special offers to users who came within one mile of REI stores.

We got a chance to enter the exhibit hall to see the booths set up by Sprint’s partners.  Of course, for me, the big draw was the Palm booth.  Palm was just setting up the booth when I got there but they were soon up and running, showing off the Pixi and Pre.  Manning the booth were lots of excited and friendly Palm folks.  I got the opportunity to meet my Palm App Catalog rep Rob Katcher, which was really great.

Following this was the keynote speech by Sprint’s president of network operations Steve Elfman.  Steve addressed the question:  Why Sprint?  The takeaway was that Sprint has the best devices and has taken an open approach.  This is Sprint’s ninth open developers conference.  He discussed how Sprint moved from a traditional provider-centric approach where they decided everything about what devices would run to what software and services would appear on those devices to a more open approach where the users and manufacturers could define those things.   Sprint has certified 300 non-Sprint devices for use on their network.  He described how they are already testing 4G in select cities and will be rolling it out to more cities.  He then said that Sprint is doing away with the call forwarding fee in mid November.  To drive home why this is important for Sprint subscribers he brought Brad Horowitz of Google onto the stage to discuss Google Voice on Sprint.  It’s clear that unlike other networks, Sprint is embracing Google Voice and consumer choice.

Following this was a Q&A session with Sprint personnel.  During the Q&A Sprint reaffirmed their commitment to open standards and open services.  They’re actively looking at how they can support industry standard API’s, even where it may conflict with technologies they had been supporting, such as Titan, which was intended to be a Java-based mobile platform.  There was also ominous discussion about tiered pricing for data.  Sprint’s contention was that the unlimited plans were put in place to get people to adopt mobile data and encourage the development and usage of mobile software.  I don’t see what benefit it would bring customers to limit them at this point.

The next session I attended was on BlackBerry mobile development.  I don’t have anything to report on this session because I don’t think anything really stuck with me except that JavaScript will have full access to the services on the device with version 5.0.  After that I attended the discussion on Sprint’s developer sandbox.  This was a more interesting discussion about a testing platform that allows developers to test their use of Sprint’s API’s without having to access their live network.  There’s a lot of power in the Sprint API so if you’re looking at developing services that take advantage of Sprint’s network API’s you should check this out.  It is important to note that these API’s can be easily accessed from webOS applications.

I decided to skip the next session to stand in the long line to get a free BlackBerry Tour.  I was successful in getting one, which I added to the HTC Hero I got last night.  Using these two smartphones really makes me appreciate what Palm has done with webOS.  Admittedly, I have not had a chance to really use these devices seriously but what’s clear is that for a user just picking up the phone for the first time the Pre really shines in usability.

After quickly ducking out of the BlackBerry session I went back to the exhibit hall to see what was going on there.  Again, I made a beeline for the Palm booth and talked some more with the folks there.  Kudos to Palm for having so many people who are excited about what they are doing.  I must say that the dinner they served was a big cut above the lunch and breakfast they offered earlier.

On a more personal note, I had a chance to catch up with a cousin here in California and went to a fantastic ramen shop.  I’m definitely going to be hunting for ramen shops back home!

Stay tuned for part 3!  Again, you can follow ‘live’ on twitter by click here:  http://twitter.com/Pre101

The first session of the morning featured Ben Galbraith and Dion Almaer of Palm.  They opened the conference by giving a little bit of their background and how they came to Palm.  They went on to discuss more about webOS and what makes it so interesting.  They were then followed by Mitch Allen, Palm’s CTO, who talked some more about webOS.  Mitch was followed by Geoff Schuller who talked the Palm’s user interface design.  Geoff was followed by Matthew Hornyak who took us further into UI and how webOS apps interface with the UI components.

Following these sessions Palm brought out the developers of some of their popular apps.  First up was Chris Sepulveda of Pivotal Labs, makers of the popular Twitter client Tweed.  He showed off Tweed and Scoop and talked about why the like developing with the Mojo SDK for webOS.  Chris was followed by Lawrence Davison of Mark/Space, makers of The Missing Sync.  One of the comments Chris made was that they at first viewed the Mojo SDK’s use of JavaScript as a problem for app development but came to realize that it was a real advantage.  The use technologies built around Web standards allowed one of their IT folks to make the transition to a developer role, which he has carried forward into other applications.

Following a quick demo of The Missing Sync we had Alex Pachikov of Evernote. After a demonstration of some of the features of Evernote Alex talked about how they had developed their own grid view widget for webOS.  He went on to say that they have opened up the Evernote API completely to developers:  The same API they use can be used by others wanting to develop apps to Evernote’s server-side.  Finally, Dan Kurtz of SelfAware Games did a somewhat trouble-plagued demo of Word Ace and talked about the process behind developing that game and the followup Card Ace.

One thing that was clear is that these developers were excited to be developing for webOS and that they were all able to develop the apps they wanted to develop with the tools Palm has provided.  After a short break they were back to answer some questions from the audience.  Some of the interesting tidbits (as tweeted) were that Pivotal has made available a DOM-less JavaScript unit testing framework called Jasmine and will be soon releasing a tool targeting webOS development called Pockets.  Also, Mark/Space indicated that all the API’s they’re using for syncing are the published APIs (as in, they are not using any special Palm-only APIs).  Ben Galbraith also said that Palm is currently synchronizing with the Webkit trunk, which will bring the browser in the Pre up to Webkit 4.  The upside of this would be much better HTML5 support, including more complete Canvas and CSS transition support.

Next up was Stephen Feaster of Palm who gave an introduction to installing the Mojo SDK.  Stephen led the crowd through the development of an application that pulled a feed from Twitter to track Caltrain delays.  This was followed by Ben and Dion discussing the app distribution channels that will be opened up to developers when the developer program is officially launched in December.  Although we’ve covered this before, the interesting new bit of information is that they will open up an API to the app distribution feed to allow developers to use the information generated by Palm for new and interesting purposes.

After this, HTC took the stage to show off their upcoming Windows Mobile and Android devices.  During the presentation I asked if HTC would be interested in creating a phone with the webOS platform if Palm were willing to license it.  The response I got indicated that there was definitely some interest in that.  Whether that would be a strategic move for Palm or not is another question.  Certainly Palm has created one of the most talked about smartphone OS’es and other manufacturers are taking notice.

In the evening, Palm and HTC each had coding conferences.  A great group of Palm staffers were on hand to help people write apps for webOS and to talk with the developers.  One thing that I took away from this is that Palm is really interested in helping out the developer community and that the developer community is really interested in working together to create something great for this platform.  The folks at webOS School were really helpful for those who were getting going with the Mojo SDK.

It’s been a long and really fruitful day.  I’m looking forward to the sessions tomorrow and getting to meet more developers and talk with the folks from Palm.  Tune in tomorrow for more!

Here’s the long and the short of it:  Jamie Zawinski, also known as JWZ, posted his perspective on Palm’s app approval process.  This process is still in beta and it’s clear that Jamie is quite frustrated by the process as it has evolved.  It’s a pretty serious allegation when a developer claims the approval process is so onerous that he’s going to stop developing for the platform.  As a webOS developer myself I’ve seen the process, though my experience doesn’t exactly mirror Jamie’s.

It seems that Jamie hit a few points in the process where he decided that he did not wish to comply with Palm’s requirements and decided to push forward hoping to get his way.  Add to that the well-known app backlog and it’s unsurprising that he became frustrated.

However, Ben insists that they are working on improving the process:

We’ve seen some folks assert that Jamie’s case indicates a general pattern at Palm that we don’t really care about developers and aren’t operating in a developer-friendly manner. While we undoubtedly have some work to do here, we hope that people do notice how we treat the “homebrew” community (e.g. PreCentral) and how our current SDK agreement calls out the inspectability and reusability of our own Palm applications. (By the way, several applications from the homebrew community have already made it into our App Catalog.)

While we have yet to finalize and announce our developer program, we hope these points demonstrate our general attitude of embracing developers and empowering them. We’re trying to strike the right balance between locking down our device and making it a free-for-all. Like all great things, this will be an iterative process and we are eager and open to your participation and input to make it better for everyone.

What does this mean to non-developers?  Hopefully, it means that Palm is serious about working with developers to simplify the submission process and make it easier to develop quality webOS applications, which will lead to an App Catalog brimming with apps.  I’m confident that Palm is heading in the right direction, particularly in light of the appointment of Ben and Dion to their post.  Sound off with your perspective below.

Updated:  Corrected Jamie’s initials.

This is very big news for the Palm Pre community.  One of the complains often leveled against the Pre has been the lack of software available for download from the App Catalog.  Unfortunately, in the short term, we won’t be seeing too many new applications there as Palm has said that it will be the Fall before they will be approving new applications.

If you’re interested in developing for the Pre head over to the Palm webOSdev site and register.  I suspect that we’ll probably also see a good bit of homebrew coming out soon, though the developer agreement seems to prohibit releasing software through other channels than the App Catalog.