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

On Mon, Apr 30, 2012 at 7:21 PM, Matt Kelly <mk@fb.com> wrote:
>> 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).

In which case it would make sense to also flag implementations that
support _both_ a prefixed and a non-prefixed version, which IIUC
above, would result in a perfect score despite fragmentation remaining
and the ability to code to specific implementations still being a
problem.

Not dropping vendor-specific prefixes despite having a non-prefixed
version still undermines the whole objective of building a reliable
baseline for web developers regardless of any given user choice of
user agent.

Received on Thursday, 3 May 2012 13:35:33 UTC