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

Re: Rough first draft of Level 0

From: Marcos Caceres <w3c@marcosc.com>
Date: Sun, 1 Apr 2012 16:54:38 +0100
To: Tobie Langel <tobie@fb.com>
Cc: "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <88AC97BF475841809BDFF7647A262CF9@marcosc.com>

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

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

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? 

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). 
> > After a million failed efforts of this sort, I really just want to see
> > this "done right" (tm) for once. I think we have the right people to do
> > it right here - but right now I fear we've already started down the wrong
> > path with the way level 0 is being written.
> I don't think form is going to make or break this effort. Shipping
> implementations will. That said, nothing is set in stone at this point.

I agree about shipping implementations. But the point should be to show what is broken and why a browser maker should be bothered enough to care.

[1] http://www.acsac.org/2011/openconf/modules/request.php?module=oc_proceedings&action=view.php&a=Accept&id=111&type=3&OPENCONF=95413ea6ce8282c8a781ec58979283a5
Received on Sunday, 1 April 2012 15:55:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:45 UTC