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: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 30 Apr 2012 13:49:57 +0300
Message-ID: <CAJQvAuc_qw7eE0GwF_KLe19ANF5X2UYkwD0ibRKWoPqNuXw+=Q@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: "public-coremob@w3.org" <public-coremob@w3.org>, Matt Kelly <mk@fb.com>
On Tue, Apr 24, 2012 at 3:37 AM, Tobie Langel <tobie@fb.com> wrote:
> 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 think it's going to be a problem if the group doesn't have a common
understanding of what it's trying to do in this area.  I think it
would be better to discuss this up front.

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

In my case personally, the outcome of this conversation would be a
pretty significant factor in understanding what this group is about
and whether what it is about is positive.

>>> 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.
>
> Yeah, that would be absurd. Thankfully, it's not the case (and if it is,
> this should be fixed).

Without having a browser that supports e.g. Animations only without a
prefix, it's hard to tell how Ringmark would behave in such a browser.
 (Determining this by inspecting the source is a non-obvious, it
appears.)

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

But this certain definition is circular.  Level zero means whatever
level of zero means without anchoring the feature set in anything else
in particular.  In that case, why can't level zero simply require
unprefixed features?

> I don't think it is the role of the CG to push non-WebKit browsers to
> implement WebKit prefixes. Quite the contrary.

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.

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

The thing is that the test suite that tests browser capabilities can't
make sure that developers target unprefixed versions if prefixed
versions pass or a particular set of prefixes if any prefix passes.

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

When it comes to a question of whether code works in a browser, using
an unsupported prefix makes code fail exactly as badly as using syntax
that differs beyond the prefix. Differing only by a prefix is a
meaningful distinction if the purpose is to endorse aliasing.

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

Not only would this avoid casual observers flipping the bozo bit, this
would set up an incentive for vendors to ship without prefix, since
doing so would reduce the red and increase the green.  It would also
discourage vendors from going from no support to prefixed-only
support, since that would increase red where there was previously only
gray.

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

Thanks.

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

Works now.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 30 April 2012 10:50:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC