Yes, that's an excellent idea. Only on correction: The de-facto mobile browser in 2010 was Opera Mini, but if you add the different Webkit versions up, Webkit will take the lead. Then again, there's a lot of fragmentation within the various Webkit based browser for iOS, Android, Samsung Bada, Blackberry 6, webOS and Symbian. http://gs.statcounter.com/#mobile_browser-ww-monthly-201007-201012-bar
The numbers differ a lot based on the region/country. Check China for example: http://gs.statcounter.com/#mobile_os-CN-monthly-201007-201012-bar Top mobile OS is Symbian with more than 70%, iOS with around 6%. UCWeb browser has a 68% market share in China, iOS browsers a 5% market share. http://gs.statcounter.com/#mobile_browser-CN-monthly-201007-201012-bar The growth rate of 3G customers in China is at more than 900% per year, and around 30% in the U.S. I've read reports that around 50% of the smartphones sold in China in the past 6 months were Android based phones. Targeting Webkit based mobile browsers is good, but you'd probably want to limit support to the key versions of Webkit-based browsers, like Android 2.1+, iOS4+, etc. On Wed, Jan 5, 2011 at 6:34 PM, P T Withington <[email protected]> wrote: > Hey Max, will you add Jira tasks for these issues, so they don't get lost? > > On 2011-01-05, at 11:47, P T Withington wrote: > > > On 2011-01-05, at 11:34, Max Carlson wrote: > > > >> It's time to add a runtime for mobile devices. Since Webkit is the > defacto mobile browser, it seems like we could benefit by stripping all the > non-Webkit specific code out of the LFC. I wanted to send out a proposal > for how we plan to do this to see if anyone has suggestions! > >> > >> First, Tucker will add a separate 'mobile' LFC build. This will use the > existing DHTML LFC build, but will also set a new compile time constant > ($mobile) to true. > >> > >> Next, I'll take the existing DHTML LFC and add if (! $mobile) {...} > blocks around the bits of the kernel that don't apply to Webkit browsers. > This will take advantage of André's recent (awesome) work to improve the > compile-time constant evaluator. Ideally, I wouldn't have to do this - the > compiler would be able to take a table of 'quirks' set for Webkit and > automatically drop out the if (quirks.foo) { ... } blocks. > > > > I wonder how hard it would be to add something like this to the compiler: > > > > #evalwhen (compile, load) { > > quirks = []; > > } > > if ($mobile) { > > #evalwhen (compile, load) { > > quirks.foo = true; > > quirks.bar = false; > > ... > > } > > } > > > > And have the compile-time constant evaluator understand: > > > > if (quirks.foo) ... > > > > ? > > > > [see: http://bit.ly/hcunZK] > > > >> Finally, Henry will remove the 'swf8' radio button on the developer's > console in favor of a new 'mobile' one. > > > > > > >
