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

Tobie Langel wrote:
> I aware of and concerned about the current prefix issues and regret the
> situation as much as anyone else here.

Note that test suites can, to some extent, affect browser priorities.
Not using Ringmark to affect the prefixing situation to the liking of
this group would mean missing opportunity to make things better.

(I think the prefixing concept is flawed so I wish scoring on
http://html5test.com/ and http://css3test.com/ didn't give a full
green pass for prefixed implementations in order to make browsers that
ship unprefixed score higher in order to incent browsers to unprefix
or to ship without prefix from the start.)

> I'm suggesting that we treat prefixes on a case per case basis depending
> on which category they fall into, as not all prefixes are created equal.

The axis of prefix inequality you mention isn't the only axis of
prefix inequality. Ringmark treats -webkit-, -moz-, -ms- and -o- as
equally satisfying the passing conditions, but in the real world out
there implementing -webkit- is more compatible with mobile-oriented
existing content than -moz-, -ms- or -o-.

> 2) After a while the spec and implementations mature and stabilize. The
> syntax is pretty much frozen, spec work is moving forward and is now
> clearly on standards track. Features is commonly used in production,
> despite still being prefixed. Now this is were things should move fast and
> haven't so far. A lot of the features devs rely on to build apps today are
> in that stage of the lifecycle.

I think the existence of this stage of life cycle is a obvious bug. If
a feature works well enough to be commonly used in production, it in
practice isn't an experimental feature and shouldn't be prefixed. I
think it would make sense for Ringmark to set up incentives that steer
towards the elimination of this bug.

> 4) Shortly thereafter implementors remove support for the prefixed version
> (this is not respected in practice).

Actually, Mozilla and Opera have removed support for prefixed versions
of CSS properties. It would be very unfortunate if removing support
for -moz- or -o-prefixed features made browsers score lower on
Ringmark and, therefore, Ringmark would end up disincenting Mozilla an
Opera from removing -moz- or -o-prefixed features.

> Coremob level 0 should be able to include specs currently at stage 2 (how
> exactly we define stage 2 can be further refined) and add a non-normative
> disclaimer for developers that they might need to prefix the property.

So what's the purpose of ring 0? What does passing ring 0 mean?

If passing ring 0 means that the browser is compatible with app
written for "Android 2.2 Froyo and iOS5 default browsers", ring 0
should be testing transforms, transitions and animations only with the
-webkit- prefix, since supporting transforms, transitions and
animations with -moz-, -ms- or -o- prefix (or with a yet-unknown
prefix!) doesn't imply compatibility with apps written for "Android
2.2 Froyo and iOS5 default browsers".

If passing ring 0 means that the browser has equivalent but
potentially syntactically incompatible capability as "Android 2.2
Froyo and iOS5 default browsers", at minimum it should be made
abundantly clear to anyone running the test suite that ring 0 isn't
testing for interop in the sense that the same code "Same Markup if
you speak MS marketese" works and is instead testing more abstract
capability. Abstract capability is a slippery slope, though, since one
might argue that totally different gradient syntaxes are of equal
abstract capability or that SQL database and IndexedDB are of equal
abstract capability.

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?

- -
A few tangential remarks:
 * It seems that letting prefixed implementations "pass" continues to
ring 1 currently, since prefixed IndexedDB passes there. Letting
prefixing continue to new stuff seems to me like Ringmark isn't even
trying to put an end to prefixing which one might sort of believe even
if transforms, transitions and animations were grandfathered somehow.
 * It seems terrible that the buckets are named "Foo" and "Foo,
standard" rather than "Foo, vendor prefixed" and "Foo" if the prefixed
buckets are going to stick around.
 * It's even worse that if you look at Ringmark in a browser that
doesn't pass ring 0, you don't even see that there's non-passing "Foo,
standard" on ring 1 even if "Foo" passed on ring 0.
 * It's very annoying that the JS at ringmark.io is minified. It's a
test suite! You are supposed to be able to easily View Source to see
what it does!
 * It seems that an update to code at ringmark.io makes the test suite
hang at "CSS 2.1" in Firefox. (I tried the same trunk build yesterday
and today. Today, the suite hangs.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 17 April 2012 09:05:16 UTC