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 : Friday, 19 April 2013 17:36:46 UTC