Lets play the intervening time forward: to get to where it is today took something on the order of a hudred million dollars in aggregate direct investment (probably more), integration with dozens of OSes and embeddings, and more man-hours of some of the smartest browser engineers in the world than I care to consider.

You can trace a similar history for Mosaic (the codebase that turned into MSHTML). Far from scoffing, I’m suggesting that there’s a huge difference between development and success as measured by distribution. Part of that process is the work of compatibility engineering (a key part of the difference between today’s WebKit and the KHTML of yore).

To imagine that there’s some other path to broad distribution is to go all-in on the “build it and they will come” fallacy that is so common in Open Source (and I’ve spent nearly my entire career — such as it is — in Open Source). They might come, but probably not. Our mental models of the world need to accommodate how un and under-informed users acquire technology too.

Regards

First, some data: we accelerate layers just fine on Chrome for Android. Yes, it was a lot of work, yes it required huge effort. But it performs well; as does fast scrolling. What FF does in these cases is a question of investment for the Mozilla organization to speak to.

But to your main point: Brendan *explicitly* called out visual glitches as a serious issue in his comments on my plus post: https://plus.google.com/113757927151929258451/posts/Q6vgGzmtNEG

To suggest that Mozilla isn’t interested in fixing these visual issues as an issue related to market penetration requires an extraordinary step away from the plain meaning of these statements (and Tantek’s in the referenced interview). Perhaps there are additive motives too, but they have not dominated the discussion so far.

As for the idea of someone creating a new system; I think you’re vastly under-estimating the number of people and amount of time it takes to create a successful web renderer. I didn’t say “good”, I said “successful”. As I try to point out in the post, product and platform are different. A big-bang event may happen for some new code-based, but nobody sneaks up on the web and converts billions of users overnight to new browsers. It just doesn’t happen.

I’m frustrated to see prominent webdevs advocating UA sniffing as a method of doing feature detection though. Once hw accelerated layers are on in FF mobile, there will likely still be hardware white/blacklists. Turning off the feature because the UA contains “firefox” will likely leave out users on newer, higher end phones where performance would be great. i.e. UA sniffing as a method of disabling effects is not generally a good idea. Feature detection (and feature performance detection if we need it) are better and more surefire ways to fix things and won’t require you to go through by hand and update them with each release.

More importantly, completely ignoring Gecko or Webkit or anything else out right now, it will help ensure that when Engine X comes out, built by Joe-Schmo in his basement, and it performs 10,000,000 times better than anything else on the market, it actually has a chance to compete as well without first having to advocate to 10,000 sites so they recognize his engine, or (more likely) resort to spoofing someone else’s UA as well as spoofing their proprietary css.

>> 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.

+1. Firefox looses customers because it (was) not innovating fast enough, and many “supported” under moz prefix features were extremely buggy (and transitions still are, for example).

You know I respect you greatly, but I’m simply laying out the implied arguments in the (disconnected) appeals that the various parties are making. If the claim of the squatters isn’t that webkit prefixes are making it difficult to prevent attrition, what is it? I haven’t hear that clearly enunciated. Or is the goal of preventing attrition — from the perspective of a product — something other than keeping users to the exclusion of other browsers which they might pick? What bit did I get wrong?

As for manpower, certain CSS WG representatives make these appeals on a regular basis.

And on the point of evangelism, I’m not claiming that web developers will do anything other than what they see is in their own interests. Evangelism has the ability to accelerate that; i.e. if a browser is becoming more popular, evangelism can have an impact on developer behavior. It has for us on Chrome for the desktop and I know full well that it did for FF too. I’m not making the (unsupportable) claim that evangelism alone can solve things.

As for what Apple’s WebKit people have said, that’s the entire reason why I’m trying to distinguish products from engines. I know that Gecko doesn’t really have this split, but Safari and Chrome already ship with different flags. That means that non-Safari ports can absolutely go their own way and add diversity to the ecosystem. Please don’t claim that what Apple says about Safari must necessarily affect other WebKit-based browsers. It just ain’t so.

To summarize: you are calling my arguments straw men on the basis of misinformation and mischaracterization. At least you’re not alone in that. There is evidently some fault to me for not writing more clearly.

Of course Tantek claims no such thing.

“Speaking of IE…I respect those guys a lot, but the logical leap they’re asking us to swallow is that the reason people return Windows Mobile phones is that some CSS doesn’t work.”

Of course Microsoft says no such thing.

“Appeals to a lack of manpower to implement must never block others and shouldn’t block standardization, so please stop making them.”

No-one is making them, as far as I know. (Although Apple is making a lack-of-manpower argument for why they haven’t standardized their new -webkit features.)

Please try to abstain from straw-man attacks.

Your point that Webkit-prefix-dependent mobile sites are not the biggest problem faced by non-Webkit mobile browsers is both immediately obvious and not relevant.

Your plea to give evangelism a chance ignores Opera’s efforts in this area, which have been going on for years, supported by a significant staff.

You may be unaware that Apple’s Webkit people have declared that they will never drop support for -webkix-prefixes. I applaud your efforts to make that happen in Chrome; that would be excellent.

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 afterall 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.

(hope that doesn’t get eaten). Sure, it’s ugly, but workable. It’s been suggested. I think the HTML spec at one point had language encouraging implementers to introduce attributes, not elements, as extension points if they wanted to extend anything.

Besides, it illustrates the point that no prefixing mechanism is necessary at all. Whether or not prefixing was possible, it didn’t happen, and it was still a success. Thus prefixes are not necessary for successful experimentation by vendors.

Aristotle: All engines have totally non-standardized prefixed properties. Gecko is no exception. There’s a whole list of them here: https://developer.mozilla.org/en/CSS/CSS_Reference/Mozilla_Extensions#Proprietary_Mozilla-prefixed_properties_(do_not_use_on_Web_sites)

In that position, it is hard to see how Mozilla can avoid implementing these properties with their -webkit- prefix. Of course that’s crazy, because it breaks the purpose of the prefix system in exactly the way you described. Mozilla is damned if they do and damned if they don’t.

The real problem is Apple obstructionism, and apparently it is also the elephant in the room.

As for Lea’s and PPK’s approaches to prefixes, those are the same damned-if-they-do-and-damned-if-they-don’t kind of reaction to the problem from the webdev perspective: dealing with lots of prefixes is a huge pain for webdevs. But the reason they have to is because the -webkit- prefix has become something other than what the prefixes in CSS were supposed to be.

And Apple is the culprit.

Apple are now what Microsoft used to be – even if maybe with less calculated intent. Is that enough to divert everybody from jumping on their case to get in line? Why are people going for these absolutely crazy coping approaches that fail to recognize the core problem – why attack the prefix system instead of indicting its (ab)use as a ruse for vendor fragmentation of the web platform?

It’s just baffling.

“prefix squatters” – he he