Announcing Sencha GXT 3.1 Beta


We’re excited to announce the release of Sencha GXT 3.1 beta, available for download here and from Maven Central. This latest release of GXT introduces Theme Builder, a new tool for theming GXT applications, as well as the Neptune theme built entirely with this tool, adds support for GWT 2.6, and fixes a variety of bugs reported by our users. We’d like to gather feedback from our community while we prepare for the general availability of GXT 3.1.

GXT 3.1 Theme Builder

Theme Builder is a tool that takes a simple config file and generates a jar file with all of the appearances necessary to theme a GXT app. The config file format allows for CSS3 values such as border radius and gradients, and Theme Builder creates appearances that can be used in browsers that may not support those features. It does this by using modern CSS and HTML where possible, and otherwise generating images of the required features.

theme {
    name = "neptune"
    basePackage = "com.sencha.gxt.theme.neptune"
    details {
        buttonGroup {
            borderRadius = 3
            border = util.border('solid', '#dfeaf2', 3)
            headerGradient = util.solidGradientString('#dfeaf2')
            font = util.fontStyle("helvetica, arial, verdana", '13px', '#666666');

While GXT 3.1 continues to support Java 6, the Theme Builder itself requires Java 7, though the code generated by Theme Builder will be compatible with Java 6. The command line tool is tested to run on both Windows and OS X, as well as several Linux distributions. The shell and batch scripts in the download zip run only on Windows or OS X to keep the zip file from being much larger. To run the script on Linux, a copy of PhantomJS will be required.

With over 350 configuration properties, almost all widgets and cells available in GXT can be themed. For all widgets displaying text, the family, size, color, weight can be specified via a single config. For widgets with borders, the color, width, style can also be specified. In many widgets, padding and spacing is configurable, as well as background colors, and sometimes even gradients.

Neptune Theme

GXT 3.1 beta includes a new theme, Neptune, generated entirely with the Theme Builder. Neptune is generated entirely from its config file, with no custom HTML, CSS, images or Java.

GXT 3.1 beta includes a new theme, Neptune.

You can use Neptune as your default theme by first moving to GXT 3.1 and then adding the gxt-theme-neptune.jar to your project. The following inherits statement needs to be added to your module file:

<inherits name="com.sencha.gxt.theme.neptune.Theme"/>

GWT 2.6

When we added support for GWT 2.6, we had to break compatibility with GWT versions 2.4 and 2.5, so any project that adopts GXT 3.1 will need to also use GWT 2.6. Moving to GWT 2.6 comes with many fixes and improvements over GWT 2.5.1 that are documented in the release notes.


With the GXT 3.1 beta release, we’ve updated our docs to include the new features like the Theme Builder, and we go into greater depth about many existing features.

Known Issues

There are a few known issues in the Theme Builder that are visible in Neptune or any other generated theme. These issues are all specific to browsers that are unable to handle modern CSS and HTML, such as IE8 and 9. TabPanel has the most obvious issues — for bottom tabpanels, the images are not aligned correctly. Dual list fields, grid row editing, and button groups do not show the same rounded corners in IE8 and 9 that you see in modern browsers. We are working on resolving some of these issues, and hope that these and other issues reported by the community will be resolved before the final release.


Creating custom themes for GXT apps is hard work for developers. With the release of GXT 3.1 Theme Builder and Neptune theme, it becomes that much easier. We are very excited about this new feature and would like to hear about your experiences. Please give us your feedback in the Sencha GXT 3.1 Beta forum so we can improve it further before the general release.

20140226-gxt-beta-teaser.jpg 4 Comments   Read more

HTML5 Scorecard: RIM BlackBerry PlayBook OS 2.0

20120426-blackberry-playbook-sm Last month, RIM released OS 2.0 for the BlackBerry PlayBook. We were already very impressed with the PlayBook 1.0 browser, and we were anticipating more, new and better. We put it through our HTML5 test wringer, and were pleased to find that the PlayBook 2.0 browser is an excellent upgrade, adding new features and upgraded performance in several areas. Notably, it features the first HTML5 color picker input type that we’ve seen on mobile, advanced SVG filters as well as a perfect Acid 3 score.

The original Blackberry PlayBook browser, released this time last year, was already a very solid HTML5 browser. In our original PlayBook HTML5 scorecard, we noted that it was far superior to the Android 3 browser and overall, an excellent HTML5 platform. We were particularly impressed with the quality of its SVG, Canvas and CSS3 Animation implementations. In this review, we’ll mostly concentrate on what’s new and improved.

In our original BlackBerry PlayBook HTML5 scorecard, we noted that it was far superior to the Android 3 browser and overall, an excellent HTML5 platform.”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in an number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. We also use a variety of homegrown and third party test-sites, including Modernizr, Acid3, and our own Sencha Animator demos and Sencha Touch Kitchen Sink.

### Device Essentials

But first up, some essentials for the web developer. If you’re looking for traffic from the PlayBook OS 2, search for the following user agent string:

Mozilla/5.0 (PlayBook; U; RIM tablet OS 2.0.0; en-US) Apple/Webkit/535.1+ (KHTML, like Gecko) Version/ Safari/535.1)

The PlayBook OS 2 supports up to 4 simultaneous touches, so interactions that rely on two simultaneous pinch/zooms are possible.

Next, JavaScript timer resolution. We’ve been looking at timer resolution on mobile lately and it can vary widely by device. For example, iOS 5.1 currently has a 4ms timer resolution with high consistency, Android 4 has a 10ms timer with low consistency. In contrast, the PlayBook 2.0 appears to have a 17ms timer. This means that script animations paced by a `setTimeout()` loop will run about 4x slower on the PlayBook 2 by default; a good reason to use explicit time in your web animations whether via JavaScript or time-based CSS3 animation. The PlayBook 2 browser doesn’t yet support the relatively new requestAnimationFrame API. For developers looking to use requestAnimationFrame cross-browser, we suggest that you use a polyfill to get the advantages of requestAnimationFrame when you can.

Perfect 100/100 Acid3 Test in the BlackBerry PlayBook OS 2 browser

Perfect 100/100 Acid3 Test in the BlackBerry PlayBook OS 2 browser

### Acid3 and Feature Detection

Just like the original PlayBook, the PlayBook OS 2 has a perfect Acid 3 score, with no rendering artifacts. Our favorite modernizr check sites, and HTML5Test report a very complete set of HTML5 features, including 3D transforms, HTML5 audio and video, web sockets, workers, web intents, SMIL, SVG and WebGL. What’s particularly nice to see is an almost complete implementation of HTML5 input types such as color picker and time.

Some minor missing features from the modernizr feature check: File API support, background-repeat, and IndexedDB. Since the only implementation of IndexedDB on major mobile platforms is the beta of Chrome for Android, this is not a very surprising omission (and WebSQL is still available anyway).

However, as we’ve noted before, just because a feature is detected, it doesn’t mean it’s working. WebGL, for example, won’t execute in a normal browser page on the PlayBook OS 2, and only activates when used in a WebWorks hybrid application. Similarly, some of the HTML5 input elements exist but you probably wouldn’t use them in their default style. For example, the time input has the unsettling habit of rewinding back to 0 when you spin past the highest value rather than looping. The color picker, while functional, is probably too spartan for use in a consumer application.

SVG Filters in the BlackBerry PlayBook OS 2 browser

SVG Filters in the BlackBerry PlayBook OS 2 browser

### Graphics Performance

In real world tests, Canvas and SVG performance was excellent, even on stressful demos like Canvas color cycle and the classic SVG floating balloon. CSS Animation performance was equally excellent. The only graphics effect we could see missing was robust support for image slicing in `border-image`. But no WebKit browser supports this feature properly yet, with the exception of recent desktop Chromes. We’re happy to report that the PlayBook 2 also has an excellent implementation of advanced SVG filters–morphology, diffuse lighting, specular lighting, custom composition filters–they’re all here. As with desktop browsers, it’s not possible yet to animate filters at an acceptable FPS, but even having static filters of this sophistication is an amazing advance for web developers everywhere. Instagram-like image effects are now available for anyone with the two to three days it takes to learn the physics and syntax of SVG filters.

Here is a screenshot from the PlayBook 2.0 of a morphology filter (from IE10’s SVG Filter demo page.)

The code for this is simple:

Just like in the original PlayBook, Sencha Animator CSS3 Animation demos work very well, handling multiple simultaneous animations smoothly and consistently.

We’re also happy to say that the PlayBook OS 2 has a rock solid implementation of `position: fixed`. Even with the fastest scrolling, we were unable to dislodge fixed content from its place on screen. `overflow: scroll` and `overflow: auto` also work smoothly (with one fingered scrolling vs. iOS’s two fingered scroll).

### Removal of Non-Standards Track Features

A last note–in a move that’s guaranteed to make anti-prefixers happy, the PlayBook OS 2 browser has removed support for `-webkit-mask`. CSS masks are very handy but have been hanging out as a WebKit only feature for nigh on four years. Although there is a new standards draft for filters and effects that aims to regularize this feature, since other engines do not appear to be on track to support the feature (Gecko wants you to use SVG masks instead), it’s probably a good idea to remove any critical dependencies on masks if you want your app to work cross platform in the future.


### A Very Fine HTML5 Browser

With the release of BlackBerry PlayBook OS 2, the RIM browser team once again delivers a high performance and up-to-date HTML5 platform for web app developers. For businesses that want to bet on a stable, state of the art device for HTML5 applications, the BlackBerry PlayBook with OS 2 is an excellent choice.

20120426-blackberry-playbook-thumb.png 12 Comments   Read more

HTML5 Scorecard: Chrome for Android Beta

Sencha HTML5 Developer Scorecard of Chrome for Android beta

Chrome for Android icon As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the new Chrome for Android mobile browser beta. There have been rumors of Chrome for Android for quite some time, and we were encouraged but a little underwhelmed by the stock Android 4 browser. We were hoping that there was more to come.

And we didn’t have to wait long. After testing Chrome for Android, we’re happy to say that it’s a very solid HTML5 browser, and even in its beta form, is a “must-install” for any Android 4 owner. Hopefully Chrome for Android quickly becomes the *only* browser for Android 4.

bq(pullquote right). If you own an Android 4, there is no question you should download and use Chrome Mobile beta as your primary browser.”

h3. Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

Chrome for Android scores a perfect 100/100 on the Acid3 test, just like the Android 4 browser. However, the tell tale rendering artifact (a very faint red/pink box in the upper right corner) that has marred a perfect score on other Android browsers, once again rears its head. (Chrome Desktop doesn’t have this artifact, so perhaps this is an OS/graphics stack issue rather than a browser problem). In practice, this won’t impact web browsing or web development much, but it would be nice to fix this for the final release.

Next up, Modernizr! Once again, we used which is a clean and mobile friendly Modernizr checker. The verdict? High marks on HTML5 support — as one might expect from the folks who brought you Chrome. Once again, the browser does have @font-face support — Google Fonts display perfectly — but TypeKit does not yet detect Chrome for Android correctly. As with the original Playbook, and Android 4 stock browser support, Typekit has a lag between first ship and support, but I’m sure the Typekit folks are on top of this.

Compared to the stock Android 4 browser, there is a substantial number of additional HTML5 features: Web Workers, Web Sockets, HTML5 Input Types, overflow: scroll, requestAnimationFrame and more. That’s not to say that Chrome for Android has absolutely everything. As detected by the other handy testing site for HTML5, many newer features are absent, notably Shared Workers and WebGL. The video codec cold war also continues: Ogg Theora and Ogg Vorbis support is still not there — which is not a surprise.

Chrome for Android running on a tablet and phone

Chrome for Android running on a tablet and phone

h3. Performance

For performance benchmarking, we use SunSpider. In the last 9 months, all the mobile browsers have converged at basically the same SunSpider performance levels. This also holds true for Chrome for Android. Although it’s slightly faster on one or two tests vs. Android 4 browser, it’s in the same general ballpark, which is not too surprising since they’re both using the V8 engine on the same hardware. Since Chrome for Android is visually much faster and smoother than the Android stock browser, this is probably a good time to consider putting SunSpider on the shelf as a good predictor of user-perceived performance.

h3. Real World Tests

As we’ve said many times previously, many mobile browsers do well on the checkbox tests like Modernizr, but fall short when it comes to real world applications and content. (In some cases, mobile browsers have even reported support when none exists.) So for real world testing, we use a collection of our own favorite HTML5 sites and demos.

First up, the new CSS properties for mobile content. On our HTML5 wish list for 2011 we asked for high performance position: fixed. And Chrome for Android delivers. For simple pages, Chrome for Android does a top notch job of glueing fixed position content to the screen. Fixed headers and footers for simple mobile optimized pages are now easily implemented without having to use a framework. However, the browser struggled when trying to maintain fixed positioning on more complex pages, particularly when combined with pinch/zoom. We saw poor frame rates and occasionally content disappeared or was misplaced. Happily, the *very new* @-webkit-overflow-scrolling: touch@ property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (Nice job Chrome team!)

On to SVG. On Chrome mobile, basic SVG worked very nicely. Our Raphael vector demos were very smooth, and many other SVG effects like text on a path, and animated gradients worked smoothly at a good frame rate. For more advanced effects (demos at David Dailey’s page), there’s still work to be done: SVG effects like complex filtering were either not supported or ran at low frame rates. Since there is little popular content that relies on these advanced effects yet, this is not such a big deal. However, when CSS Filters start to percolate into general usage, getting these right will become more important.

We next tried Canvas and here Chrome for Android has a good implementation. Basic Canvas drawing is unproblematic, and our favorite Canvas stressor — Canvas Color Cycling was smooth and high performance even under pinch/zoom. The most complex demos we could find (that can cause even desktops to pause), such as the demos at Mr. Doob did cause some problems — with long wait times and occasional complete display failures.

Our testing of embedded HTML5 audio and video went well. Plain inline HTML5 video works, (although don’t try to combine it with other effects or Canvas). This is an area where Chrome Beta has the advantage over iOS 5 which still lacks inline video playback.

Finally, we took a look at CSS3 Animations & Transforms. This is an area that we’ve invested in here at Sencha with Sencha Animator. Poor Android performance on 3D transforms has been a limitation on the complexity of CSS animations that can deploy cross platform. Our most complex animation — our Sencha Animator KickFu game — was playable, but the frame rate was too low for a smooth experience — I’d estimate a 5-10 frames per second performance. More basic CSS3 animations — even 3D ones — worked well, although we did uncover our first official bug for the Chrome team which we will be filing — transformed elements seem to drop border-radius. In addition, there are a few layout quirks that are present in desktop Chrome for transformed elements that also show up in Mobile Chrome.

h3. Sencha Touch 1.0 Kitchen Sink

Although we’re in late beta with Sencha Touch 2, we decided to test Sencha Touch 1.1 instead. Compared to Android 4, the Chrome for Android experience is vastly improved. Full-screen flashes and screen flicker are absent. Other things that we take for granted such as smooth border radii, masking etc. are also well implemented. But it’s also true that some of the browser properties that we rely on for layout in Android are now different in Chrome Beta and these result in minor artifacts in layout and list scrolling that we’ll need to be address.

h3. Chrome for Android beta: tips for the HTML5 developer

Chrome for Android is a big leap forward for web browsing on Android devices — even in its beta form. We suspect that many of the browser limitations are limitations more of the device processors than the browser itself. There is still work to be done before general release, but in all we’re very happy to have a top notch browser for Android. If you own an Android 4, there is no question you should download and use Chrome for Android as your primary browser as soon as you are able.

20120209-chrome-for-android-thumb.png 14 Comments   Read more

How to Embed Interactive CSS3 Animations in an iBook

Sencha Animator animations playing in an Apple iBook

Click through to see a video of Sencha Animator animations playing in an Apple iBook.

Like everybody else on the US west coast, this morning we woke up in a world where Apple is poised to transform the way we consume textbooks. One of the compelling features of this new and exciting medium is the ability to easily publish interactive books through iBook Author.

iBook Author lets you embed interactive content in your books to create more engaging experiences for learners, and our first thought here at the Sencha HQ was to try using Sencha Animator to create that interactive content.

So after a few minutes of fiddling, we found a fairly straightforward way to embed an Animator project in an iBook.

h3. Step 1: Preparation in Animator

Open a Sencha Animator project you’d like to place inside your iBook. Take a screenshot of the stage area to create a “cover” for the animation, and rename it “Default.png”. This cover image will be used to show the animation in the page when inactive. Make sure it’s the same size as the stage.

Sencha Animator Rocking Boat project

Sencha Animator Rocking Boat project. See the animation and our original article, Rocking the Boat of Flash with CSS3 Animations.

Export the project as you normally would, then place your Default.png inside the output folder.

h3. Step 2: A Little Hacking…

Now comes the tricky part: you need an “info.plist” descriptor file in your output folder, so we provided one ready for you in our project file available to download at the bottom of this article.

Edit the info.plist file to enter the dimensions of your animation, then the BundleName to match the export folder’s name (e.g. myExportFolder), and finally add the extension “.wdgt” to the folder.

If you’re working in Mac OS X, the icon of the folder will change to that of a Dashboard widget. If you’re on Windows or Linux, you can create a widget but you will need Mac OS X Lion in order to complete the process, since iBook Author only runs on that version of Apple’s operating system.

h3. Finishing Up in iBook Author

iBook Author and Sencha Animator in action

iBook Author and Sencha Animator in action. Download the project files below to get started.

Now that you have an animation file ready, you just need to add an HTML widget to your book, and drag the .wdgt file in the widget’s properties as we show in the screenshot.

Now you’re ready to export your book and enjoy the results of your work! Of course, you’ll need the new iBooks Author app and Sencha Animator on your Mac. Download our demo Sencha Animator iBook project below to get started.

* Download Animator->iBooks Project File
* Start your 30-day trial of Sencha Animator 1.1
* Download iBooks Author from Apple (Available for free on the Mac App Store)

sencha-animator-1.png No Comments   Read more

How to embed interactive CSS3 animations in an iBook

Like everybody else on the US west coast, this morning we woke up in a world where Apple is poised to transform the way we consume textbooks. One of the compelling features of this new and exciting medium is the ability to easily publish interactive books through iBook Author.

iBook Author lets you embed interactive content in your books to create more engaging experiences for learners, and our first thought here at the Sencha HQ was to try using Sencha Animator to create that interactive content.

So after a few minutes of fiddling, we found a fairly straightforward way to embed an Animator project in an iBook.

Step 1: preparation in Animator

The first step requires to create a new project, or use an existing one and create a “cover” for the animation, and rename it “Default.png”. This cover image will be used to show the animation in the page when inactive, and needs to be of the same size as the stage.

Sencha Animator Rocking Boat project

The next step is to export the project as you would normally do, then move the previously created Default.png to the output’s folder.

Step 2: a little hacking…

Now comes the tricky part: you will need a .plist descriptor file in your output folder, so we provided one made for you to download.

Edit the .plist file to match the dimensions of your animation, the BundleName to match the export folder’s name (e.g. myExportFolder), then add the extension “.wdgt” to the folder.

If you’re working in MacOS, the icon of the folder will change to that of a Dashboard widget. If you’re on Windows or Linux, you can create a widget but you will need Mac OS Lion in order to complete the process, since iBook Author only runs on that version of Apple’s operating system.

Finishing up in iBook Author

iBook Author and Sencha Animator in action

Now that you have an animation file ready, you just need to add an HTML widget to your book, then drag the .wdgt file in the widget’s properties like shown in the screenshot.

Now you’re ready to export your book and enjoy the results of your work! You can download our demo book from this

No Comments   Read more

Sencha: The 2012 HTML5 Wishlist

Our Top Ten HTML5 Wishes for 2012 It’s that time of year, and we’re once again publishing our HTML5 wishlist. But before we do that, let’s see how our 2011 wishes went. On balance, we didn’t do so bad. Out of our ten wishes, four came through. Here are the HTML5 wishes that became reality in 2011. We wished for:

* A richer CSS3 effects toolbox; and lo there was CSS Filters, a port of the sophisticated filters available in SVG to the DOM.
* High performance position: fixed for mobile browsers; and we were granted it in iOS 5’s Mobile Safari. Now we’re waiting for other devices to catch up.
* Pervasive GPU acceleration; and we were pleased to see the BlackBerry PlayBook and Android 4.0 join iOS’s excellent implementation of accelerated graphics.
* Websockets stabilization: and we got a Christmas present of RFC 6455 and the W3C Candidate Recommendation for the web sockets protocol and API respectively.

But our other six wishes didn’t fare so well. There was only minor progress toward deeper device access on mobile browsers and developers continued to use native wrappers to access cameras and microphones. WebSQL stayed dead as a standards track technology (and its performance even decreased in iOS 5). We also saw slow progress on IndexedDB implementations. The rival HTML5 codec camps remained entrenched with little prospect of harmony, even as the mobile patent battles raged across global jurisdictions and institutions, and live debugging on mobile browsers remained a difficult task.

In the “welcome surprise” category, Microsoft impressed us with its support for HTML5 in the IE10 preview, showing a solid commitment to the latest HTML5 and CSS3 standards. Finally, and disappointingly, many of WebKit’s nicest proprietary extensions, like @background-clip: text@, remained off the standards track and omitted from other browsers.

So, looking forward to 2012, we’ve got a new top ten wish list for HTML5 and for the browser makers. Some of 2011’s top wishes make a comeback, but others are brand new. We don’t claim these are definitive, but a motley collection of what we think would be most interesting for developers creating the rich and responsive applications that HTML5 was built for.

h3. 10. HTML Media implementations

Although we got some support for photo uploads in Android, web browser support for media capture and other HTML5 media technologies remains elusive. As a result, mobile web developers, in particular, have to wrap their web apps in a shell to get device API access. Camera access is the #1 feature reason for HTML5 developers to deploy to native rather than web, and given Apple’s leadership in almost every other area of mobile web, it remains a glaring omission for Mobile Safari.

h3. 9. HTML5 audio quality

While long-playing HTML5 audio works in most places, short-form audio, particularly for the features that games need, is lacking. Synchronizing audio with video or animations, multi-channel and mixing are all features that developers want. There are a number of early stage drafts to create standards for richer media handling, so that’s encouraging. Perhaps by the end of the year, we’ll be looking at solid desktop support, at the very least, with some standardization in round 2 of working drafts. We wish.

h3. 8. Better Offline Caching

HTML5 cache manifests are great for basic offline application support, but they require developers to know in advance what their assets are, declare them in a file and link the file into their pages. Mobile browsers in particular have had idiosyncratic and occasionally buggy interpretations of cache manifests. So, we’re wishing for a more dynamic, easier caching mechanism, ideally one that has some JavaScript APIs.

h3. 7. Web Intents: Standardization & support

Web Intents are a great mechanism to allow web applications to hand off tasks to one another, without knowing in advance who and what the offloading web app is. Invented by Paul Kinlan from Chrome, and inspired by Android’s intents system, they’re a neat way to allow web applications to collaborate on tasks. We’re wishing for a speedy standards track draft and good interoperable Firefox and WebKit implementations by the middle of the year.

h3. 6. WebGL Everywhere

It’s here, it works, it’s gorgeous. We’re even supporting a framework for WebGL. It looks fantastic on desktop. Our (probably fruitless) wish for 2012 is that IE10 supports WebGL, and we get ubiquitous WebGL on mobile. With iOS planning to support WebGL only within iAds, at least for now, it looks like we might wait a while to get that broadly, but we’re wishing for it anyway.

h3. 5. IndexedDB

2011 put a stake through the heart of WebSQL (thanks to Mozilla’s leadership) but IndexedDB is not ubiquitous yet. On desktop, Safari has yet to ship it, and it’s not here on mobile. Until then, developers continue to roll their own shims on top of local storage and WebSQL to get cross-browser offline data storage. We’re wishing for IndexedDB everywhere this year.

h3. 4. Right-sizing images src helps developers deliver the right image size to any mobile device, but in our opinion this is a neat solution for something that should be solved in standards. Karl Dubost from Opera points out that there was a proposal back in the day to enable this at the HTTP layer. However, given today’s cloud environments where developers often dont get to tweak their web servers and vanilla HTTP is the only thing available, this won’t fly. It needs to be added to either HTML or CSS. We’re hoping the CSS4(!) Images standard now in “pre-draft” form will get some love and attention this year.

h3. 3. Contacts API

We’d like contacts access without having to use a shell API. So would lots of our developers. There’s a spec from Nokia and friends but too few implementations.

h3. 2. Background Services

We’d also like to see more capabilities for managing multiple resources and handling background tasks. Chrome, once again, is leading on implementing these OS-y type services. Web notifications are in working draft and we wish they get broader implementation this year. We’d also like to see server-sent events get the wake-up behavior that’s spec’d.

h3. 1. Better Mobile Browser Debugging

And for the second year in the row, we’re asking for better mobile browser debuggability and profiling. Chrome’s remote debugging feature has been made to run on BlackBerry PlayBook, there is no reason others can’t follow it. Scriptable debugging/profiling would greatly assist mobile application QA, something that’s currently a painful task in mobile web app (and framework :-) ) development.

So that’s it! We know lots of our wishes have to do with mobile, since that’s where new technologies get adopted and reach critical mass the fastest. But it’s also the environment that’s hardest to hack around shortcomings, since the iOS and Windows Phone environments are so tightly controlled. And there’s a much longer list of things that we could add here (better, easier crypto for one, WebCL and more) but we’ll stop here in the interests of brevity. What’s your favorite wish for 2012? Give us your feedback in the comments!

14 Comments   Read more

HTML5 Scorecard: Amazon Kindle Fire

As part of our continuing series, we ran the new Amazon Kindle Fire through our tests to see how it stacks up as an HTML5 app platform.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, we’re taking the measure of the new “Amazon Kindle Fire”: When the Kindle Fire was announced, we were excited about getting our hands on it. As the first mass market tablet at the $200 price point, we knew it had a good shot at selling millions of units. But at the same time, we were apprehensive that Amazon might have skimped on hardware capabilities to reach that price. We were also concerned about the browser platform. The Fire runs a customized version of Android 2.3.4 (Gingerbread) and in the past, we’ve been disappointed with the quality and completeness of that browser. We were hoping that Amazon would improve the stock Gingerbread browser significantly.

The Kindle Fire is a competent but minimal HTML5 platform that reflects its $200 price and Android 2.x lineage.”

After putting the Kindle Fire through our test wringer, we can say that while it’s a solid browser for normal page browsing, it lags the best of the competition in HTML5 capabilities. Constrained by its Gingerbread foundation, it’s a competent but minimal HTML5 platform that reflects its $200 price point. At this stage in the tablet game, we would expect better.

h3. Our First Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

The Fire scores a less than perfect 95/100 on the Acid3 test. Like other Android tablets, it lacks SVG support and incorrectly displays the Acid3 visual test compared to the reference implementation. With both the iPad2 and the BlackBerry PlayBook now scoring 100/100, this puts the Fire behind the pack. In addition. the Fire failed test 46 (media queries) and came in slower than required on three other tests including the self-described “challenging” test 26 for garbage collection speed.

We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. Since the Fire hardware lacks a camera, an accelerometer and a GPS, some of the results (geolocation failure!) are predictable. What Modernizr did find was support for CSS 2D transforms and Canvas as well as other Android 2.x capabilities. Notably absent: 3D transforms, web sockets, web workers and many HTML form input types. Again, not that surprising considering the Android 2.x heritage.

Happily, web fonts seem to be well supported. Both Google Fonts and Typekit dynamic fonts render correctly. But Typekit font loading and page scrolling on the Google Fonts page (with tens of different onscreen web fonts) was noticeably slow.

h3. Performance Testing

When checking the user agent received, web servers report that our Fire was using WebKit version 533.1, which is much older than the WebKit found on the Xoom and PlayBook. On other hand, when the Kindle is put in “desktop browsing mode”, it advertises itself as Safari 5/Mac OS X/Webkit 533.16. Under the hood, according to the iFixit teardown, the Fire contains a dual-core ARM processor, specifically the TI OMAP 4430, which is the same processor as the BlackBerry PlayBook. We therefore expected SunSpider scores in the same range as other tablets. As we’ve mentioned before, this current generation of tablets all ship with dual-core processors and all have roughly the same JavaScript optimizations. So the results are again fairly predictable.

Amazon Kindle Fire SunSpider results

For the most part, the Amazon Kindle Fire has similar SunSpider results compared to Apple iPad 2 and BlackBerry PlayBook.

The SunSpider tests are synthetic tests that push the JavaScript engine to its limit. So, next we turned our attention to some more real world tests, looking at CSS3 performance using our own Sencha Animator demos as well as a few other tests.

We threw caution to the wind and started off on our most challenging CSS3 animation test, the Kick Fu game that was developed for the launch of Sencha Animator. While the game did play, the frame rate was poor and touch responsiveness while animations were running was also substandard. The Fire lacks a separate GPU, but the CPU has a competent GPU core – and even so, it looks like it wasn’t leveraged for hardware acceleration. The Playbook, for example, does a far better job leveraging the same GPU core.

Next we tried simpler animations. The Fire performed more smoothly, but had a notably bad implementation of timing. In the video below, the wave movements are controlled by CSS3 animations and are declared at constant speed. Instead, the animation speeds of each element diverge and lag noticeably and visibly from each other. We’ve never seen artifacts of this magnitude before. This got us wondering about the Kindle’s general timer quality, so we ran John Resig’s classic JavaScript timer test and found that the quality of the timer is similar to other Androids: with setInterval triggered every 10ms +5/-3s, with some noticeable latency spikes. (This compares to iOS 5’s best-in-class implementation of 10ms +/-1ms.) This isn’t supposed to matter as much once people get used to using requestAnimationFrame for JavaScript animations, but the Fire doesn’t have that either.

CSS3 Animations on the Amazon Kindle Fire

We also tested a few other real world areas for performance and correctness. We tried a Canvas based GitHub network graph. Rendering performance was fine and the result was accurate. Pinch/zoom happily also works although Android’s tendency to toggle into low-quality mode when moving content reared its head once again. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid and we were able to change the scene without issue. However, like all webkit implementations, all bets were off when we zoomed and panned the page. Animation stuttered, froze and occasionally the accompanying audio cut out. We also looked at other Canvas animations and they worked at reasonable frame-rates.

Finally we tested embedded HTML5 audio and video. HTML5 audio playback seemed to work well, although the default playback controls were tiny, hard to touch and didn’t seem to work very well. HTML5 video is “supported’ but tapping play simply launches the video in the native player. Complete HTML5 video support with embedded playback and effects is not there. There also appears to be no Ogg Theora codec on the device as we couldn’t get any Ogg Theora demo to play.

The Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal.”

h3. Sencha Touch Kitchen Sink

Our Kitchen Sink app is built with Sencha Touch and tests all aspects of our mobile web app framework. The Kitchen Sink gives mobile browsers a good workout as it exercises a huge set of browser features including a wide range of CSS3 effects.

The first thing we noticed were the crispy CSS rounded corners. They’re not anti-aliased properly on the Fire. Webkit masks are also not supported. Then we got our first really big surprise of our run through. We found that the Kindle Fire has problems processing touch events with good responsiveness. Update: and we’re not the only reviewers to notice this . And similar to early HTC phones (since fixed), the OS and browser seem to fight over who gets touch events. Sencha Touch 2 was designed to adapt to this behavior, so the Touch 2 preview kitchen sink works better than the Touch 1 version. And of course, since the Fire is based on Android 2.x, full multi-touch with independently tracked touches is not supported either.

As you’d expect with a device lacking a GPU, graphics effects like transitions were less than smooth, although display artifacts were not as bad as the full screen flashes and repaints that are a problem on honeycomb based tablets.

h3. No to low Impact from “Accelerated Browsing”

Amazon Silk One of the main selling points of the Kindle browser is supposed to be its cloud-caching and pipelined HTTP connection that uses the SPDY protocol. This does seem to speed up normal page browsing a little, but it’s not very noticeable and we didn’t test this rigorously. But for HTML5 web apps, where code is downloaded and executed, there doesn’t seem to be any performance difference when we tested with acceleration on and off. It doesn’t appear as if client JavaScript is executed on the server-side at all, so the Kindle does not seem to have Opera Mini-style server-side execution. And SunSpider scores were essentially the same when accelerated browsing was turned on or off.

Side-by-side comparison of accelerated vs. unaccelerated browsing for some popular web home pages.

h3. Kindle Fire: Suggestions for the HTML5 App Developer

In summary, the Amazon Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal. It does a good job of displaying ordinary web pages and its resolution and rendering capabilities meet that need well. But there are too many sharp edges, performance issues, and missing HTML5 features for us to recommend that any developer create web apps primarily for the Kindle Fire. The iPad 2 running iOS 5 continues to be the tablet to beat, with the PlayBook a respectable runner-up in HTML5 capabilities.

sencha-html5-kindle-fire-thumb.jpg 20 Comments   Read more

Apple iOS 5: HTML5 Developer Scorecard

Apple iPhone 4S with Sencha logo Whenever a new device or mobile operating system comes out, we do our HTML5 Developer Scorecard to help folks who are building mobile web apps understand how to take advantage of these new devices. In early October, iOS 5 (and the iPhone 4S) was released. In our last few reviews, iOS has come head and shoulders above other device platforms as the best platform for HTML5 developers. High performance, hardware accelerated rendering, super quick JavaScript, and speed of adoption of new HTML5 features, it’s been the best platform to build modern web apps on.

Mobile Safari continues to hold the crown as the best mobile browser, providing the best HTML5 developer platform.”

The latest Mobile Safari on iOS 5 continues in that tradition. Mobile Safari continues to hold the crown as the best mobile browser, providing the best HTML5 developer platform as well as adding new features and improving others.

As usual, we looked at the basics of the browser: JavaScript and HTML/CSS rendering. For raw JavaScript execution speed, iOS 5 (with the iPhone 4S) isn’t much of a surprise and looks a lot like any other dual-core mobile device (such as the PlayBook and the iPad 2). It scored 2,275ms on the SunSpider benchmark: a solid score, but nothing new in the current hardware landscape. Things that iOS was good at continued to be good, such as smooth and fast hardware accelerated CSS3 transitions and animations. Our typical Sencha Animator tests ran smoothly and continued to render at a higher frame-rate than any other mobile device we’ve seen.

Given how good Mobile Safari has been, we didn’t run the browser through the usual paces we would have. Instead for this HTML5 Developer Scorecard, we took a look at the things that are new or better on the latest Mobile Safari:

* Canvas is crazy fast. In iOS 5, Canvas is between 5x – 8x faster. We tried two examples to see this work. First, the IE HTML5 “Speed Reading”: Test. In iOS 4.x, the draw durations last roughly ~850ms, versus iOS 5, where they are a constant 10ms. Since that might be too synthetic, we also tried the Flash Canvas “image manipulation benchmark”: It reports the number of milliseconds the manipulation sequence takes. On iOS 4.x, this was ~19,000ms, but on iOS 5 it reported ~450ms. As with all benchmarks, take the result with a grain of salt, but for game developers building on Canvas, iOS 5 is a *much* more attractive platform for graphics.

* WebGL logoWebGL is supported. Sort of. If you’re an iAd developer, you can use WebGL in your ads, but you can’t use it through Mobile Safari or through a wrapped UIWebView. This is a limitation put in place intentionally by Apple as it’s possible to “work around”: the restriction in a wrapped UIWebView, but only by linking to private APIs — which means you can’t submit the resulting app to the app store.

* You can use compass directions! The DeviceOrientationEvent now supports compass headings via a new webkitCompassHeading property. The property gives you the device’s orientation relative to magnetic north. Check out James’ “sample”: on your iOS 5 device to see it working.

* Better CSS position and overflow support. In iOS 5, position: fixed and overflow: scroll both work. If you’re looking to add some scrollable areas with native feeling bounce, you can now do it with these CSS properties. You don’t get a ton of control but if you’re looking to have a scrollable area in your web app, this is a really quick way to get it. There’s also a special iOS property, -webkit-overflow-scrolling: touch, which changes the scroll behavior to be more “iPhone”-like.

* WebWorkers work! In our testing we confirmed that WebWorkers — the API to let you spin up background “threads” is now enabled in iOS 5. It makes sense that this arrives just as the iPhone goes multi-core. This is great for developers who need to do some background processing in their application. That can be data updates to a server, or preprocessing some information, or anything else you can imagine when you don’t want to block the main browser UI thread. Now that iOS 5 has support for the API, we’re interested to see how it’ll end up being used in mobile (and in using it ourselves).

* HTML5 form fields are supported, including number, range, and date picker. This is great for an HTML5 developer because iOS now opens the appropriate on-screen keyboard based on the input tag type.

* XmlHttpRequest, level 2 is supported. Anybody who builds complex apps that use XHR to talk to a server is used to the hacks that XHR level 1 required. In iOS 5, XHR level 2 is supported so you can use capabilities like cross-origin support, binary data support, and more.

Apple iOS5 icon Mobile Safari in iOS 5 continues Apple’s tradition of delivering a first class browser and innovating in device APIs. Of course, there are more we’d like to see soon, primarily the MediaCapture APIs so web developers can get better access to the device camera. We’re particularly happy about the super-fast Canvas and really interested to see what developers will do with WebWorker support in mobile.

ios5-sencha-thumb.png 10 Comments   Read more

Sencha Animator Released: A Revolution in Mobile Animation

Sencha Animator Released: A Revolution in Mobile Animation

h3. Introducing Sencha Animator 1.0

We spent the last few months working very hard (and very quietly) to bring you a product that we think will redefine the creation of animations on mobile devices. And now it’s here: today we’re very proud to announce the first release of Sencha Animator.

View Sencha Animator CSS3 Demos Download Sencha Animator

h3. What is Sencha Animator?

Sencha Animator is a desktop application that enables interactive designers to easily create rich media animations based on web standards for modern mobile devices. Until recently, rich media advertising on the desktop web has been enabled by the Flash plugin. But with no Flash support on iOS, interactive designers have been looking for a way to bring animations and rich interactivity to mobile devices without hand-coding hundreds, if not thousands of lines of JavaScript, CSS3, Canvas, or native code.

Museum of Science demo advertisement

Museum of Science demo advert, tailored for iPad dimensions

Last year, we looked at the various techniques for mobile animation and decided to focus initially on CSS3 Animations. Animations built with CSS3 have a considerable advantage over any other mobile animation technique: they look, feel, and run beautifully. And on most mobile browsers CSS3 is hardware accelerated, so it consumes very little CPU power while running at high framerates. In addition, since CSS3 Animations are just styling, browsers that don’t support them can still fall back to viewing un-animated content.

For these reason, we decided to start out using CSS3 animations. We try to be as faithful as possible to the underlying technology in Animator. We’re giving designers a simpler way to build animations while making the output friendly to hand-editing and further extension.

View Museum of Science Demo video

The road to CSS3 animations

During the last year, the Animator team at Sencha has worked to bring an innovative technology in a familiar working experience to interactive designers and creative agencies. Those of you who followed the evolution of Sencha Animator will appreciate how much we’ve refined your working experience.

Every area of the product has been honed and perfected with community feedback and a fantastic group of professional designers and user experience experts contributed to the creation of a user interface that is both easy to use, yet extremely powerful.

And while the first release of Sencha Animator produces WebKit compatible animations, but now that CSS Animations are also part of Firefox, Opera and IE10, we’ll be adding support for those browsers in time as well.

Each design decision has been made with a conscious effort to help designers be as productive as possible, as quickly as possible. So let’s go over the major features of Sencha Animator 1.0:

Sleek Dark UI

h4. A UI that gets out of your way

The Sencha Animator interface is designed using dark tones to let designers concentrate on what really matters — their own creative work — while the tool chrome fades into the background. Key actions in the UI are highlighted with accent blues to guide designers to available actions.

On top of the visual design, Animator focuses on productivity. To make it easier to work on small screens, almost every panel is collapsible so you can maximize the canvas area. Keyboard jockeys can use the arrow keys to nudge objects. Smart guides are triggered when moving objects on the canvas to help align things properly on the fly. To make it easier to see the results of edits, properties in the Property panel feature “drag to edit” and keyboard increments/decrements so designers can adjust properties to exactly the effect they want.

h4. Intuitive timeline, multiple scene support

The timeline is the heart of any animation: it’s here where you can take a static object and bring your artwork to life. For each object on the stage, the animation track shows its visibility, the presence of keyed animations and their timing. The track is easily editable with the mouse, and can be finely customized by using one of our pre-set easing curves or with the powerful custom easing tool.

Every object, and object group, can be locked and hidden to facilitate tweaking of individual elements, and a simple but effective “scene end” marker lets you define the length of each scene.

Animator supports complex nested objects, but it’s easy to tell if anything is happening inside a collapsed nested group at a glance by using the nested animation indicator.

Nested timeline collapsed

Nested Timeline Expanded

For bigger and interactive projects, putting everything in a single timeline can become confusing and hard to manage. The Scene system allows you to split your projects into several scenes keeping the timeline free from clutter and your project better organized.

By default, when a scene is finished, the animation will go to the next scene, however this can be customized in different ways (more on this later). Scenes can even be previewed by hovering on its thumbnail, making it easy to find the right one to edit.

Multiple scenes at your fingertips

h4. Object Library

Animator also offers an Object Library that lets you save your objects for later reuse in the same project, and for use in a different project via export. This new feature facilitates the creation of multiple animations using the same branded elements (logos, buttons, etc) and simplifies the job of maintaining a consistent look and feel across multiple projects and collaborators.

Object Library

h4. Templates

In studios and agencies, interactive designers often find themselves working on multiple projects for the same client, or building multiple creatives for the same device. Animator makes this easy for designers, letting you save a project as a template, then start a new project from that template. Templates are simple Animator files that can easily be shared with colleagues and collaborators and used as a consistent starting point for projects.

h4. Advanced interactivity and output options

This is the piece interactive designers are going to love the most: Animator lets you use JavaScript almost everywhere. You can add JavaScript to objects, to scenes or in the head of the exported HTML + CSS output. In a scene’s properties for example, you have the ability to add interaction at the scene’s start, at the end and on mouse/touch move. There’s a choice of pre-packaged interactions like opening a URL in the same window, skipping to another scene, or adding your own JavaScript. In addition to this, Animator output is intentionally highly human readable.

You can also choose to minify your export, or to activate ORMMA support. Designers unfamiliar with web technologies have direct access to the exported code, so they can easily understand how their creations work under the hood, while advanced users have complete control over the output, giving them the freedom to push the envelope. And pushing the envelope is not an expression we’re using lightly here. Just take a look at the demo that our beta tester agency created with Animator:

KickFu game demo

KickFu game demo, made with Sencha Animator by View video of demo

When we saw this for the first time, the offices at Sencha were speechless with what a skilled designer can do with Sencha Animator, and we hope you will be too.

h4. ORMMA Support

Animations are a key part of any interactive brand campaign, and Sencha Animator makes it incredibly easy to build advertising assets. Animator produces creatives that are compatible with any mobile ad network that can serve rich media ads. This is thanks to our support for an up-and-coming standard called ORMMA (Open Rich Media Mobile Advertising). All major mobile networks support it, and it eliminates the need to code an ad for a specific network, and reduces re-work that’s often required to run campaigns on multiple systems and apps.

ORMMA logo

With Sencha Animator, designers don’t have to develop for the lowest common denominator anymore, but build experiences that are designed to work on different devices, ad networks and delivery methods.

Go ahead, amaze us

As you can probably tell, we’re incredibly excited to release Sencha Animator, but we didn’t do it alone: we had the help and support of an incredible group of artists and developers from various backgrounds that were so gracious to help us test the product and helped us fine tune it. A special thanks goes to the many people that have contributed their critiques, suggestions and guidance to Animator. We should also note here that we built Sencha Animator itself using Ext JS wrapped with native packaging: this has allowed us to simultaneously ship versions for Mac, Windows and Linux.

Sencha Animator icon

We can’t wait to see what all of you will be able to do with Animator, and we are excited that you will surpass our wildest expectations. Go ahead, download the trial and we look forward to being amazed.

h3. Pricing and availability

Sencha Animator is available today at $199 from the Sencha Store. Discount packs are also available.

sencha-animator-1.png 21 Comments   Read more

IE10 Preview: HTML5 First Look

Internet Explorer 10 logo

Over the last year we’ve been putting every new major mobile platform through a battery of tests to assess how they stack up as an HTML5 application platform. So far, it’s been thumbs up on Apple, RIM and HP tablets and thumbs down on Android tablets. But we’re still crossing our fingers that the Ice Cream Sandwich release of Android will make the grade.

To date, we haven’t spent time on Windows phones, mostly because the Windows Phone 7 browser was so poor that it wasn’t worth evaluating. However, at the Windows Build conference last week we got our hands on a developer preview tablet running Windows 8 and Internet Explorer 10. We wanted to share our first impression of the HTML5 experience. Simply put, (and with the caveat that we were running on the notably overpowered developer preview hardware) the IE10 HTML5 experience is one of the best we’ve seen on any platform to date. After a decade of web neglect, Microsoft is back with a vengeance.

h3. The Windows 8 Web Platform

Windows 8 Metro platform

Before we go into the details of HTML5 support in Win8/IE10, it’s probably worth stepping back and covering some essentials of Windows 8. Windows 8 represents a big shift in Microsoft strategy because it makes web technologies a Tier 1 development option for native Windows apps.

To repeat: **applications developed in JavaScript/HTML/CSS can now be built and distributed as native Windows applications**.

The core Windows services for graphics, i/o, device access etc. all have JavaScript bindings equally as rich as the bindings for developers working in .NET or C++. The Microsoft message is that you can now build any native Windows app using web technologies.

So… what will be the differences between simply developing a web-based app for use by IE10 and developing a web app that gets delivered as a Win8 native app? The first difference is the resources that you’re allowed to access and how you’re allowed to access them. As a web-based app, you don’t get access to protected system resources such as camera, printers etc. To package your web app as a native app, you must create a permissions manifest file describing the protected resources that your app wants to access, and then submit your app to the (forthcoming) Windows app store. On submission, it will be checked for compliance with a battery of technical and policy tests.

Although it wasn’t altogether clear from Build, our guess is that app store compliance testing will be Microsoft’s mechanism for controlling web technology evolution on the Windows platform.

h3. HTML5 Support

So, what’s new in IE10? A huge number of new features, particularly in the area of UI elements and effects. The IE10 preview supports almost every visual HTML5 and CSS3 feature that’s been introduced in the last three years and several more besides. IE9 was already a serious step-up for Microsoft with capabilities such as hardware accelerated Canvas, but IE10 introduces much more including:

* CSS Transforms and Transitions: 2D and 3D transforms work smoothly and at high quality. Anti-aliasing and perspective handling for 3D transformed elements is visibly superior to many other browsers. And the smoothness of transforms is impressive which means that they’re probably hardware accelerated.
* CSS Animations: are fully implemented with the syntax pioneered by WebKit. This is very exciting for us because it means that Sencha Animator animations play easily on IE10 with a simple find/replace of –webkit to –ms.
* CSS3 Shadows: both text and box shadows are completely supported (including inset shadows!). Combining shadows with other effects works flawlessly.
* CSS3 Gradients: fully supported with new style webkit/mozilla syntax which allows circular and elliptical radial gradients among all the other options
* And that’s just the start. There are also web workers, web sockets, web fonts, Indexed DB, SVG filters, flexbox layout. Border-image seems to be the only thing not implemented.

Remarkably, particularly for developers trained to look out for Microsoft platform tie-ins, there are none on this list. Microsoft simply implemented the draft standards with no extensions or gotchas.

h3. Microsoft Gets Some Firsts

In addition to substantial catchup on UI-related features, IE10 also pioneers some new technologies that haven’t made it into other browsers yet such as CSS Regions and positioned floats. CSS Regions is a working draft authored by Adobe that enables newspaper style layouts with features like irregular inserts that span multiple columns, as well as configurable text flow around floating elements. These are very useful for publications that want to duplicate print-style layouts on the web. (Finally, Microsoft is still pushing grid layout, although it continues to be the sole browser that implements it, and predecessor specs have languished in the CSS working group for years.)

IE10 also has some nice extensions for touch interfaces that control scrolling and pan/zoom on elements. For example, the new -ms-content-zooming CSS property controls zoomability and the -ms-scroll CSS properties control scrolling behavior. These do not seem to be standards track yet, so it would be good to see some working drafts from Microsoft covering these new properties.

h3. What’s Missing From IE10?

With all the substantial catchup, there are a number of notable HTML5 technologies that haven’t appeared in IE10, and given Microsoft’s platform strategy, seem unlikely to ever show up there. First, WebGL is explicitly off the menu. To work with 3D graphics, it seems that web developers will have to use the JavaScript bindings to Windows Direct graphics APIs and distribute their apps only as Windows apps. Similarly, media capture and Device APIs are missing and given the thrust of the strategy, seem unlikely to show up anytime soon. These are the types of API’s that Microsoft wants you to consume via native bindings.

h3. And What Will Ship?

If you couldn’t tell already (!) we’re very excited by Windows 8 and IE10. We think it cements HTML5 as the standard cross-platform app development tech. We wish we didn’t have to use native packaging to get access to interesting device API’s, but Microsoft is unlikely to implement these without a competitive spur. The final, but major, caveat is whether all these technologies will retain their speed and performance when Windows 8 is squeezed onto next year’s $299 tablets which are likely to have a GigaByte of memory and a lower-powered ARM processor.

We certainly hope so.

sencha-HTML5-IE10-metro-thumb.png 25 Comments   Read more