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

RE: Purpose of ring 0 and vendor prefixes (was: Re: Ringmark is now open source)

From: Matt Kelly <mk@fb.com>
Date: Mon, 30 Apr 2012 17:21:10 +0000
To: Henri Sivonen <hsivonen@iki.fi>, Tobie Langel <tobie@fb.com>
CC: "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <9A96676420EDC341844B0BD0878509E6438AAEC1@SC-MBX01-4.TheFacebook.com>
> Depending on whether implementing -webkit-prefixes makes some tests
> pass, this CG might de facto endorse -webkit-prefixes.  I'd much rather see
> the group take deliberate stances in the area of the prefix
> endorsement/non-endorsement then letting endorsements happen
> implicitly and semi-accidentally.
> > One of the goals of Coremob
> > should be to incentivize developers to not write WebKit-only code.
> As far as I can tell, Ringmark currently poses no such incentive.

We test for non-prefixed features in Rings 1 and 2.

> >>OTOH, if ring 0 is about abstract capability rather that complete
> >>compatibility all the way to the exact syntax, why not redefine it so
> >>that passing ring 0 means supporting the abstract capabilities of the
> >>intersection of the "Android 2.2 Froyo and iOS5 default browsers"
> >>feature sets but with standard syntax?
> >
> > That's pretty much been the goal all along, modulo acknowledging (in
> > some form or other) that some of the features, although implemented as
> > per specs, might only be available prefixed in some deployed browsers.
> > Happy to see we're converging. :) I'll edit the Wiki accordingly.
> As far as acknowledging goes, it is a problem to test only unprefixed features
> and not acknowledge the existence of prefixed implementations in any way.
> This could lead to a situation where a browser user runs the test suite in
> Safari and flips the bozo bit on the test suite if the test suite claims that Safari
> supports none of transitions, transforms or animations.
> To address this problem, rather than have prefixed and unprefixed versions
> of a feature as different buckets, the test suite could have three outcomes
> for each test: feature absent (gray), only prefixed (red; not counted towards
> score; doesn't unlock the next ring) and pass (green; feature supported
> without prefix). This way, the presence of prefixed features could be
> acknowledged while still treating them as not passing the suite.

Yes, this makes sense.  We want to award innovation (new features that need to be prefixed), but also award reducing fragmentation (after a feature becomes a standard).  I'll provide some updates once we start working on making this clearer in Ringmark.
Received on Monday, 30 April 2012 17:21:46 UTC

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