Re: Ringmark is now open source

On 4/12/12 11:21 AM, "Thaddee Tyl" <thaddee.tyl@gmail.com> wrote:

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

There's a lot of different audiences to a test suite. But let's move away
from Ringmark to discuss the specs themselves.

>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 kind of features we are talking about here don't empower users
directly. They empower app developers to build applications that
themselves empower users.

So interoperability is key. One of the easiest ways to achieve it is to
implement the same set of useful standards across implementations. And
given the plethora of standards, some useful, some less so; some finished,
some mere drafts; it's important to be able to define and agree upon which
are the ones that really matter, so that app developers can build
applications that work across devices. This is really what this CG is
about.

>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 think there's a gross misunderstanding here. Again, the aim was never to
write a spec that described the implementation of a given set of browsers.

What we found out when talking to developers (and yes, obviously that was
a biased sample, whose isn't?) is that the features set they expected to
be supported when developing apps corresponded roughly to those available
on both early android phones and iOS devices.

The intersection of these two feature sets also happens to be a rough
subset of the features you find implemented in Chrome for Android,
Fennec/Firefox Mobile, Android Browser, Mobile Safari, IE9 mobile and
Opera Mobile. It so happens that the most deployed browser is also the
worst one and doesn't have a clear upgrade path. If that sounds familiar
it's because it is.

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

That's roughly what we've been arguing for.

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

There's ongoing standards work at the W3C for that, notably in the WebApps
and DAP WG.

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

Have you looked at the Wiki? Content of Level 1 is described there.
Vaguely on par with your suggestions, but more focused and realistic in a
short time frame.

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

Agreed. Let's focus on the spec.

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

All the features I'm suggesting make their way into the specs are on
standards track (if not yet recs). All of them are implemented in all or
most of the following browsers: Chrome for Android, Fennec/Firefox Mobile,
Android Browser, Mobile Safari, IE9 mobile and Opera Mobile.

That said, there's a small number of non-standard features developers have
come to rely on (e.g.: H.264, mp3) which are much more problematic to
include in a spec (they're proprietary, patent-encumbered, etc.). Whether
or not the CG decides to include those in the specs, and if it does, how
it decides to include them is an important question with important
repercussions. The CG will have to discuss this (not in this thread,
please!) and come to agreement.

--tobie

Received on Thursday, 12 April 2012 11:01:29 UTC