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

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

From: Rich Tibbett <rich.tibbett@gmail.com>
Date: Thu, 3 May 2012 15:34:39 +0200
Message-ID: <CALmeN0c=PpW-qgC0R1KGHhxdSny7z+ha8tDiLeCEDWAeGke-sg@mail.gmail.com>
To: Matt Kelly <mk@fb.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, Tobie Langel <tobie@fb.com>, "public-coremob@w3.org" <public-coremob@w3.org>
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

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

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