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

Re: Ringmark is now open source

From: Tobie Langel <tobie@fb.com>
Date: Sun, 15 Apr 2012 00:25:11 +0000
To: James Graham <jgraham@opera.com>
CC: Thaddee Tyl <thaddee.tyl@gmail.com>, "lbolstad@opera.com" <lbolstad@opera.com>, "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <CBAFD975.799D7%tobie@fb.com>
On 4/14/12 11:46 PM, "James Graham" <jgraham@opera.com> wrote:

>I'm suggesting that in general we avoid considering a prefixed
>implementation sufficient

Agreed. It's only something that makes sense for special cases.

>and in the case we allow special dispensation
>(e.g. where there are several interoperable implementations with prefixes
>but the relevant WG are dragging their heels for some silly reason, but
>people are unwilling to unprefix) a feature that is only implemented with
>a prefix is at best a partial credit e.g. the test box goes orange rather
>than green.

I suggest we defer making such decisions until we have a precise idea of
the number of specs concerned by this.

>I am furthermore suggest that any prefixed implementation with different
>semantics to the standard is a fail. There is no difference between such
>thing and a proprietary API that happens to provide the same features as
>standard API.


>Note that this seems to be an entirely different philosophy to the
>ringmark tests which afaict indiscriminantly try some well known prefixes
>on all CSS property tests.

If that's so, then we should fix it.

>(an aside: is 
>really the original unubfuscated code I am supposed to be reading? It
>looks like minified code that went through a beautifier to fix the

Yes, I'd also like to see the original script. :-/

>> Coremob Level 1, on the contrary would explicitly prohibit this through
>> global disclaimer E.g.:
>>    Prefixed implementations by themselves cannot claim conformance.
>I have a feeling that people will expect the rules for passing level 1 to
>be like the rules for passing level 0. So I am unwilling to accept that
>shouldn't carefully consider the effects of allowing prefixes in level 0
>or the precedent it sets.

I don't necessarily agree with your feeling. I think this can be mitigated
by setting clear expectations. That said, I suggest we revisit this once
we've have a better idea of which specs are concerned by this issue.

>>> I don't see any reason not to require ES5.1 support. Or rather I don't
>>> any reason to prefer partial ES5.1 support over full support.
>> We should aim for full support of ES5.1 in coremob level 1. If level 0
>> to be a de facto standard, there aren't enough compliant ES5
>> implementation in the wild yet to justify making full support an
>> requirement.
>[citation needed]
>I'm 100% sure that there aren't any "compliant" ES3 implementations; it
>simply isn't possible to be 100% compliant and work on websites.
>I believe that all current browsers target ES5.1 and, at least on
>desktop, most browsers do very well on the testsuite.

So I absolutely agree both specs should give a very clear signal that ES5
is the target. I don't want to make all of ES5 a requirement in level 0
as a) devs don't rely on all the features and b) there aren't any fully
compliant (mobile) implementations yet.


Received on Sunday, 15 April 2012 00:26:07 UTC

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