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

Re: Ringmark is now open source

From: Thaddee Tyl <thaddee.tyl@gmail.com>
Date: Thu, 12 Apr 2012 11:21:36 +0200
Message-ID: <CAE3TfZPWn9pcZ-zbSJ6MM+j5_W0HN7Qh-EZdMgZfuveYYmfi5A@mail.gmail.com>
To: andrea.trasatti@nokia.com
Cc: public-coremob@w3.org
On Thu, Apr 12, 2012 at 6:08 AM,  <andrea.trasatti@nokia.com> wrote:
> On Apr 11, 2012, at 1:12 PM, ext Charles McCathieNevile wrote:
>
>> This is the key question - what should be in Ring-0? And this is where I think we are starting in the wrong place. Beginning with the browsers made by the people who make the platform we're trying to bring to the Web is, in my opinion, getting a little too cosy for comfort. Most of the Web is not specific to those browsers, and our goal is presumably that none of it will be. Otherwise why would people whose goal is to build the Web be interested in this work?


This is a valid concern. Ringmark is targeted at phone browser makers.
Phone browser makers don't want to "have the same features as
smartphone X". They want to spend time developing useful features that
empower users.

The two main smartphones that seem to be in the current ring 0 are
both webkit-based. Well, webkit includes a lot of non-standard or
prefixed functionality. Including those is dangerous, because we
cannot expect other browsers to implement vendor prefixes from webkit.
Indeed, that would defeat the purpose of prefixes. Similarly,
non-standard behavior should be discussed with other browser vendors
before being standardized. Yet those features are taken for granted in
Android and in the iPhone.

I can go on and on about why I believe targeting specific phone
browser versions is bad.

>
> I am going to throw a different idea here to define ring 0 and all the later rings.
> We want to talk about "Web apps" (which is different from an individual, maybe static, Web page on a Web site) and we want to make sure developers can create great Web apps that give that native-app feel.
>
> Can we forget about market share and can we focus on what the developers need in order to create these Web apps? We should define what a Web app is, at least at high level. A very rough definition could be "A Web app is an application developed using a mix of HTML, JS and CSS, accessible via a user agent, self-contained and mimicking the behaviour of a native application". This has a bit of my own thinking and a bit stolen from Dom's blog [1].
> Once we have this basic definition we can move on to identify which browser features (not browsers or browser versions), present in current browsers (and again we MUST define a time window because who knows what Opera Mini can do with an update very soon!), allow Web developers to create such Web apps. This would be ring 0.

Again, I don't like the "current browsers" thing. What should a
browser vendor implement to provide a feature set on a par with "other
browsers"? (Please note that we are talking about "browsers" in
plural, which will be relevant below.)

Ring 0 should be a set of CSS3 specs, HTML features, some of SVG 1.1,
and the complete ES5.1 implemented.

The next rings can probably benefit from the ideas that have stemmed
from the B2G project: What does the Web APIs need to do what native
apps do?

That includes things like camera access, accelerometer, certain
requirements for playing sound right, etc. and even the Vibrator API,
battery management, sending phone calls and SMS, … but I digress.

We should discuss which CSS3 specs and HTML features we include in
Ring 0, not which browsers we should look up to!

The approach I would like to have is the following: if a feature is
present in at least two engines (by the way, Webkit counts for one,
but JSC / V8 are two), and behaves the same in those engines, and is
implemented as per the spec, then it should be in Ring 0.

Having two implementations of a feature means that the feature isn't
browser-specific (or engine-specific, which is even more pernicious).
If two different engines have implemented the feature, then so can a
third!

A feature that is backed by two engines give a lot more confidence in
its robustness, thus providing a greater incentive to implement it.

Getting the list of features matching that definition is hard work. We
should all collaborate on getting this work done.
Received on Thursday, 12 April 2012 09:22:10 UTC

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