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: Tobie Langel <tobie@fb.com>
Date: Tue, 24 Apr 2012 00:37:23 +0000
To: Henri Sivonen <hsivonen@iki.fi>, "public-coremob@w3.org" <public-coremob@w3.org>, Matt Kelly <mk@fb.com>
Message-ID: <CBB5EB38.7A42E%tobie@fb.com>
On 4/17/12 11:04 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:

>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 worried this could be a heated debate and I'd rather punt for now.

>> 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-.

Good point, I was looking at it from a developer's perspective, but from a
vendor's, the story is obviously different.

>> 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
>> haven't so far. A lot of the features devs rely on to build apps today
>> 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.

Others will disagree. Let's not have this conversation for now. :)

>> 4) Shortly thereafter implementors remove support for the prefixed
>> (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.

Yeah, that would be absurd. Thankfully, it's not the case (and if it is,
this should be fixed).

>> Coremob level 0 should be able to include specs currently at stage 2
>> exactly we define stage 2 can be further refined) and add a
>> 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".

Thanks for bringing in a vendor's perspective here, that helps me think
this through.

A browser passing ring 0 should mean that it is compatible with apps
written for Coremob level 0.

Writing an app for Coremob level 0 implies coding to the standards
specified in the Coremob spec while being aware that a small subset of
them aren't yet implemented unprefixed in existing browsers. I think it is
important for the spec to mention clearly (but non normatively) which
standard features are potentially only available prefixed on existing
devices as it will considerably lighten developer burden.

I don't think it is the role of the CG to push non-WebKit browsers to
implement WebKit prefixes. Quite the contrary. One of the goals of Coremob
should be to incentivize developers to not write WebKit-only code. I think
this is best done by acknowledging the prefix issue, scoping it to a known
set of features, making sure developers targeting these also provide
unprefixed versions, and ideally, prefixed versions for all concerned
browsers and not just WebKit-based ones.

>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.

There's a distinction to be made between features that only differs by a
vendor prefix and those that differ by syntax.

>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.

>- -
>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.

That's an accident. Matt can you fix this?

> * 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.

Also agree naming is unfortunate. Matt, can we fix?

> * 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!

Afaik the unminified src made a significant difference in load time. We
compromised by pointing to the unminified src from a comment in the HTML.

> * 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.)


Received on Tuesday, 24 April 2012 00:37:56 UTC

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