Update (2011/05/26)
Added a couple of request I’d previously overlooked; Remote Debug API & Better support for window.print()

The guys over at Sencha have just posted their wish-list for the 8 things they want to see in iOS 5. As you might expect they’ve focused on the improvements they’d like to see in Safari.

Of the 8, these are what I consider the most important:

1. WebGL

   WebGL would suddenly provide JavaScript developers with an opportunity to create rich, graphic-heavy games, simulations, and other applications

   There’s been a lot of really great WebGL demo’s lately, all of which currently require Chrome. I’d love to see WebGL make an appearance in iOS5 & also be brought from the WebKit nightlies into an updated Safari build!

2. CSS Improvements

   There is a cottage industry of JavaScript hacks to overcome the lack of a few critical CSS properties — in particular position:fixed and overflow:fixed. Sencha Touch makes it easy to develop apps with fixed tool bars and inner scrolling, but having native browser support for these properties would be useful, especially if done in a way which plays well with viewport and orientation changes.

   This is my single biggest wish for iOS5, the need for Javascript hacks to provide fixed toolbars is ridiculous! Sencha’s own scrolling is among the best I’ve seen, along with the recently written Scrollability by Joe Hewitt. However it would still be much more efficient to let the browser/OS handle scrolling natively.

3. Viewport Improvements

   Some apps (particularly games) are often designed to be used only in one orientation or another. Unlike native apps, there is currently no way for an iOS web application to prevent viewport rotation, and the ability to enforce this would be a welcome addition to the web runtime.

   This is definitely a must, especially if they do add WebGL support.

   Also, viewport settings currently have to be prescribed in markup, and we’d like to see them overridden in vendor-specific CSS, where they probably always belonged.

   The current meta tag support is useful but it does pose some problems, especially if you wish to treat different devices differently. Suppose you’re using media queries to render your site differently for iPhone & iPad, you may wish to prevent scaling on iPhone but not on iPad. This (as far as I have found) isn’t possible without conditionally adding the metatags server side.

   If these viewport controls were controlled via CSS then we could use the same media queries to deliver different settings to different devices!

I’d also like to see:

1. Better support for adding bookmarklets

   The current process for adding a bookmarklet in Mobile Safari is so user hostile! Marco Arment wrote an open request for better bookmarklet support in October of last year, hopefully this is something that will be resolved in iOS5. Bookmarklets are an important piece of the puzzle to extend the reach of both webapps and native apps on the platform.

2. requestAnimationFrame()

   The new requestAnimationFrame() would mean that:

   The browser can optimize concurrent animations together into a single reflow and repaint cycle, leading to higher fidelity animation. For example, JS-based animations synchronized with CSS transitions. (via Paul Irish)

   Essentially its better than using setTimeout()!

3. Keyframe events for CSS3 Animations

   This one is more for iOS5.1. Currently Javascript events are not fired at each keyframe in an animation, just at the start and end. I recently wrote a Javascript shim to provide CSS3 Animations with events at each keyframe. A feature request to add this natively to WebKit has been raised (#61208) and hopefully this will be available in a future release.

4. Remote Debug API

   This in my opinion could be the single biggest advance in webapp development! The new WebKit Remote Debugging API would allow for a fully featured inspector view of your app as it is deployed on the device. The Blackberry Playbook already supports this, I’d love to see iOS be the next to implement it.

5. Better support for window.print()

   When AirPrint was introduced in iOS, window.print() worked when used inside MobileSafari but not in a fullscreen webapp launching from the homescreen. Until this is fixed the only option is to write a native wrapper app to expose the print support to a UIWebView object.