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

> 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