Sencha Notes

Alex Russell wrote a piece about the CSS vendor prefix debate, and our CEO Michael Mullany responded with a piece of his own. You should head over to Alex’s blog to read what is now an epic comment thread, but we also felt we should share it here with everyone.

Click through to read about Sencha’s stance on this issue, and why we don’t see a WebKit-only future.

Originally posted by Michael Mullany at Infrequently.org, February 17, 2012 at 4:21 pm:

Since both sides of this debate make claims to “what developers think/act”, we thought we’d lay out the Sencha opinion on -webkit prefixed effects: why we use them, and why we don’t want other vendors squatting on them. And incidentally, we’re fans of CSS as a technology.

But first a little background.

Here at Sencha, our frameworks haven’t focused on progressive enhancement: in our opinion, it’s not very appropriate for apps. A grid that degrades to a poorly laid out table is not generally useful, not for developers, not for users. Our community’s users expect their web apps to look and behave exactly the same, whether they’re in IE6 or Chrome 17. This has not been easy to achieve. It’s not just a matter of adjusting to the well known problems such as IE6’s broken box model, but also working around a multitude of other browser quirks (such as the extensive bugs in IE’s VML implementation for our web charting.) Suffice to say, as a cross-platform framework company, we put a lot of time behind abstracting browser inconsistencies.

When it came to developing Sencha Touch in late 2009, we took a slightly different tack. Our primary goal was to create a web framework that could provide a native-quality application experience.

Quite quickly, we figured two things out. First, most smartphone hardware on the market simply didn’t have the power to run high quality experiences in their browser. Second, many mobile browsers (Blackberry OS 5, Windows Mobile 6 CE etc.) lacked the JavaScript engine or the CSS support that we needed to create compelling user experiences. With these two constraints, we decided that our initial version of Sencha Touch 1 would target just the built-in browsers for both Android and iOS. Luckily, at the time, those two browsers were responsible for the vast majority (90%+) of all mobile web traffic in the U.S. (as measured by ad requests http://www.slideshare.net/admobmobile/ad-mob-mobilemetricsapr10). Our interpretation was that other platforms were delivering such a bad experience that few people were using them for regular web browsing.

The biggest benefit of targeting just these two browsers was that we could take full advantage of the huge set of -webkit visual effects – which were then mostly available only on WebKit-based browsers. Gradients, transforms, transitions, border-radius, and CSS masks were indispensable in creating the richest experience possible. Even though they were technically experimental, most of them had standards track documents that meant that we could rely on some form of the capability being a standard at some stage for other browsers, if and when they arrived on volume mobile platforms.

Using WebKit effects reduced the size of our download package (far fewer images), allowed for easily themed applications, and drastically increased the performance and smoothness of our animations. In particular, CSS 3D transforms were hardware accelerated on iOS, which delivered noticeably better frames per second when compared to JavaScript-based animations. Without WebKit effects, we simply wouldn’t have been able to deliver the quality of product that we needed.

Subsequent to our release of Touch 1.0, there have been a bunch of new mobile browsers from RIM, Mozilla, Opera and Microsoft. We’ve added support for RIM and announced our intention to add support for Windows Phone. As a leading implementor of “WebKit” only mobile frameworks, we’re often asked when we’ll add support for these browsers. Here’s how we think about this.

For us, “supporting a browser” is not just a matter of adding multiple vendor prefixes or doing feature detection. Every single browser we support —even the supposedly generic WebKit ones— have had major differences in the correctness and performance of features, which makes the “use feature detection” approach advocated by many fairly useless. We have browser specific code for Android 2.2, 2.3, and 4. We have code just for the Kindle Fire and code just for the Blackberry Torch. Our list scroller implementation for Android Gingerbread is based on scroll position animation and our list scroller for Android 4 is based on CSS transforms. This attention to detail, and our browser-specific code, is needed to create the most compelling experience possible. It’s why people use frameworks rather than try to code to the naked browser.

In addition, we’re a developer’s developer, so we care about supporting the browsers that our developers care about developing to. Today, that means Android, iOS and Blackberry. Soon it will be Windows phone. This means that a lot of -ms is going to start showing up in our CSS files, and it also means that we’ll be replacing WebKit-specific effects that do not look like they are headed to standards track. The two major effects that are only are truly useful but have no standards track document yet are background-clip: text and CSS masks. (There is an aspiration to move these effects in to a general FX spec at some point in the future, but we would have much preferred that Apple or Google submit standards track documents for these much, much sooner.) These are now supported in both Firefox after a fashion as well as WebKit. These effects are useful for theming icons and other small graphics that can be delivered as custom fonts. For Windows Phones, we’re looking at the prospect of using image based theming, fonts or SVG masks. But we hope IE implements CSS masks soon too.

On the other hand, we see only minor demand from our developers that Sencha Touch work on Firefox Mobile or Opera Mobile because each of these has much lower levels of usage on smartphones. But this isn’t the only reason that we don’t support them, it’s because in our opinion, the quality of the implementation of the effects that we need to use is often much poorer in these browsers (although we’d also cast stones —big ones— at the Android 3 browser). If Mozilla decides it’s going to expropriate -webkit prefixes and masquerade as an iOS browser, we can see a requirement for us to figure out a different way to detect that it’s Firefox and disable those effects.

At a higher level, we agree that it’s very odd behavior for Mozilla to cry wolf about a WebKit-only monoculture when their implementations of the effects that we and other developers are most excited by have been dilatory and underwhelming. And, we’re not worried about a WebKit-only monoculture, it’s clear that IE10 has a pretty good shot at overturning WebKit as the best browser on Windows. At the very worst we’re looking at a duo-culture.

So after all that context, here’s what we’d like to see.

First, no prefix squatting. It’s a terrible idea and will make developers go through contortions to route around it. Daniel Glazou’s proposal that it’s ok to squat only in the smallest possible way, may not be a terrible stop gap, but we’d still prefer “no squatting period”.

Second, a much stronger effort from the browser makers to move experimental effects into standards track. At most, there should be a 6-month delay between first ship and an Editor’s draft at the very least. Even now there are a ton of effects that remain outside standards track. Just two more examples, WebKit text decoration effects should be integrated into CSS Text. And CSS Masks —which arrived in WebKit in April 2008!!— should have long since been put into a track document.

Third, more aggressive pruning of non-viable standards track features or even whole standards track documents. For the longest time, the CSS Text spec was a peculiar species of speculative fiction. I can point to other living dead spec documents. It’s not very helpful when we have to read transcripts of meetings and long discussion threads just to figure out what we can count on and what we can’t. And waiting for something to hit Candidate Recommendation status is not realistic.

Fourth, more aggressive pruning of experimental features that have been rejected as ‘a bad idea’ by the CSS Working Group. There needs to be a “negative standards doc” listing things that “ain’t going to happen”. It’s been very clarifying for us for WebSQL to be declared a dead end (although we personally liked its functionality quite a bit.) Once a feature hits the negative standards track, browser makers should have 6 months to remove it from their edge versions.

In any case, this is the take on the prefix kerfuffle from the perspective of a mobile framework developer. Enjoy.