Re: Ringmark is now open source

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
>a 
>thing and a proprietary API that happens to provide the same features as
>a 
>standard API.

Absolutely!

>Note that this seems to be an entirely different philosophy to the
>current 
>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 
>https://github.com/coremob/coremob-tests/blob/master/suite/_resources/h.js
> 
>really the original unubfuscated code I am supposed to be reading? It
>looks like minified code that went through a beautifier to fix the
>indentation).

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

>> Coremob Level 1, on the contrary would explicitly prohibit this through
>>a
>> 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
>we 
>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
>>>see
>>> 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
>>is
>> to be a de facto standard, there aren't enough compliant ES5
>> implementation in the wild yet to justify making full support an
>>absolute
>> 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
however 
as a) devs don't rely on all the features and b) there aren't any fully
compliant (mobile) implementations yet.

Best,

--tobie

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