This story was written by Keith Dawson for UBM DeusM’s community Web site Develop in the Cloud, sponsored by AT&T. It is archived here for informational purposes only because the Develop in the Cloud site is no more. This material is Copyright 2012 by UBM DeusM.

The State of Mobile Browser Monoculture

Talk of a Webkit monoculture in mobile browsing has been controversial. Firefox wants to help.

What has been a highly competitive desktop browser landscape is slipping towards monoculture on mobile devices, due to the prevalence of the Webkit rendering engine. Mozilla wants to help.

Webkit is the rendering, or layout, engine behind the Safari and Chrome browsers and thus has the home-court advantage on the dominant mobile platforms, iOS and Android. Webkit is also the engine that must be used by any competitive browser running on iOS -- at least any which the developer hopes to get approved for listing in Apple's App Store.

At the moment, Safari claims 65.8 percent of the mobile browser market, with the Android Browser (also Webkit-based) taking second place with 19.2 percent, according to Net Market Share. That's 85 percent between the two leaders. Opera Mini is in third place with 10.6 percent -- but Opera's stance vis-a-vis Webkit is complicated, as explained below.

webkit-icon-3

Some see a threat to the open Web in this confluence of technology. With Webkit's dominance, many mobile developers were becoming lazy, according to this view. (Another observer holds that the problem is not a Webkit monoculture, but rather an blindness to any but Apple devices on the part of mobile developers.)

Consider the CSS problem. The prefix feature in CSS3 was intended to allow Web developers to avail themselves of experimental HTML5 / CSS3 functions in some browsers before they have advanced to the status of inclusion in the standard, while maintaining broad compatibility with other browsers. Here's an example: the CSS transform property has been partially implemented in the various browsers over the last few years. The Webkit version of this function, whose syntax may differ from the emerging standard, is accessed via the keyword -webkit-transform. Similarly, Opera uses -o-transform; Internet Explorer, -ms-transform; and Firefox, -moz-transform. The developer includes all of these forms -- plus the to-be-standard one -- in CSS files for maximum compatibility. Each browser honors its own prefixed version of the property and ignores all the others. Once a standard is finally agreed upon, each browser can drop the prefix and simply use transform.

But browser makers began seeing more and more Web sites whose CSS was coded only with the -webkit prefix -- that is, no other browsers were special-purposed, and the lazy developers didn't even include the un-prefixed, standards-target forms in their CSS. Thus Opera, for example, which is perfectly capable of rendering HTML5 effects such as transforms, transitions, and border-radius, never got the chance, and users of such non-Webkit browsers were relegated to a non-optimal or even a broken experience.

Early this year Opera began hinting that their browsers might honor the -webkit CSS prefix, in addition to, or even ahead of, their own designated -o prefix. Standards-conscious developers hated this idea. Opera followed through on the promise (or threat) in April, and last month announced that -webkit would be honored by a development build of version 12.50 of its mainline Opera browser.

Opera Mini runs in all mobile environments. In most it is based on Opera's Presto rendering engine, but on iOS it must render via Webkit to abide by Apple's rules for the App Store. So far at least, Opera Mini honors its own -o CSS prefix and ignores -webkit. But the pressure must be significant to change that stance.

Now, Mozilla is an organization born and bred to abhor monoculture and to champion open Web standards -- Its Firefox browser was the first to make headway against Microsoft's IE monopoly, and it opened the door for Chrome and Safari. The organization has decided to do some outreach and education around Webkit and Web standards. This effort began with offering a survey intended to get a better picture of how mobile developers actually stand in relation to Webkit. Besides asking whether developers are testing on any browsers other than Webkit-based ones, the survey explores what libraries, conversion tools, and visual tools are in use. The thinking is that a Webkit bias goes deeper than the developer community, extending into the tools and libraries developers are using. A little education directed at the toolmakers could go a long way towards restoring a more standards-friendly balance to the mobile Web.

Mozilla has now reported on early results from the survey. A somewhat gratifying 71 percent of the developers (or of that subset of developers who target Web delivery, it is not clear) claim to test on non-Webkit browsers. That number's believability is somewhat undermined by the prevalence of Webkit-only tools. Among the reasons developers gave for not testing outside of Webkit, the most common one was lack of time.

What do you think, is there a Webkit monoculture in mobile? Let us know in the comments.