W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: Rough first draft of Level 0

From: Tobie Langel <tobie@fb.com>
Date: Sun, 1 Apr 2012 16:48:47 +0000
To: Marcos Caceres <w3c@marcosc.com>
CC: "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <CB9E4CF3.741C3%tobie@fb.com>
On 4/1/12 5:54 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:

>On Sunday, 1 April 2012 at 15:58, Tobie Langel wrote:
>
>> On 4/1/12 4:21 PM, "Marcos Caceres" <w3c@marcosc.com
>>(mailto:w3c@marcosc.com)> wrote:
>> 
>> > I think many people will be confused, as I was, by the use of RFC2119
>> > terminology. Can we change is to show stats instead?
>> 
>> I'm not sure I understand what makes a de facto standard a bad candidate
>> for specification. Can you elaborate? (I mean, outside of the obvious
>> issues in Coremob level 0 like proprietary APIs, patent-encumbered
>>codecs,
>> etc. which are orthogonal issues.)
>
>I think we might have an terminological or ideological misunderstanding
>here.

Shoot, we better figure out which one it is! The former's easy to fix, the
latter usually not so much. :-/

>In the doc, you initially start out by saying "we need these bits of
>HTML", but then start mandating full support for full specs. This doesn't
>get to the core of the problem: even if you "support" a spec, the support
>may be poor. For example, SVG may be supported by a mobile browser, but
>it may perform really badly and so making it unusable by developers:
>hence, it complies to Core Mob, but you don't win anything that improves
>the platform for developers.

I concur.

>On the other hand, if you have a game/app that demonstrates clearly that
>when you overlay some SVG on some video while relying on WebSockets to
>move some charters around a screen the browser comes to a screaming halt,
>then you have a much stronger case (as you can show that the use
>experience sucks).

We can't build an app for every non-working use case and expect
implementors to run them all to improve their browsers. But we certainly
need perf benchmarks and quality of implementation guidance for
implementors, both backed by use-cases.

> 
>> > > Yes, that is the purpose of Cormob level 1, which will go in the
>>details
>> > > of the features missing to build around 90% of the top 100 "native"
>> > > applications on the Mobile Web Platform.
>> > 
>> > That's excellent to hear, Tobie. This is not captured very well
>>anywhere
>> > and I think it should be (hence my little skeptical outburst).
>> 
>> I tried to give context in the wiki. It's still a work in progress atm.
>
>Understood. The context should really be in the spec (hopefully the wiki
>will just serve as a place to put down some temporary ideas, and not
>something we come to rely on too much).

Yes. It's a brain dump. It'll make its way into the spec.

>It would be great if we could document that list of apps. Having said
>that, aren't 86% of the top 200 free apps (top 20, across 10 categories)
>already using a Webview on Android? [1]. If so, is that not indicative
>that the platform is doing pretty well?

Think that data would be relevant if these apps were just an embedded
webview. In truth, they're not, they're using webviews for part of the app
but not for all of it. It's the missing parts we're aiming to pinpoint
with Coremob Level 1.

>Instead, it might be better to select some really innovative applications
>that are pushing the envelope (i.e., things likely not in the Top 100 -
>but are considered "ground breaking" or pushing a platform to the limit).

Heart-fully disagree. This is exactly what has been done so far and what
gave us a platform that does great 3D and super slow 2D while more than
90% of the top games (free, paid, grossing) on iOS are, in fact, 2D or
isometric games. Before tackling ground-breaking apps, let's target more
mundane ones.

--tobie
Received on Sunday, 1 April 2012 16:49:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC