Re: Ringmark is now open source

On Sat, 14 Apr 2012, Tobie Langel wrote:

> On 4/13/12 7:31 PM, "James Graham" <jgraham@opera.com> wrote:
>
>> FWIW I expect the confusion here arises from the fact that ringmark tests
>> things that are only to be implemented prefixed (per e.g. CSS WG
>> guidelines), and considers an implementation with a prefix to be a pass.
>> I think this is a very problematic approach; prefixes are bad for the long
>> term health of the web and at best should get partial credit; we should
>> be putting pressure on the CSS WG to unprefix things that we think are
>> needed today rather than promoting the user-hostile, developer-hostile
>> status-quo of long-lived fragmentation.
>
> I aware of and concerned about the current prefix issues and regret the
> situation as much as anyone else here. But I'm also trying to have as
> objective a viewpoint as possible and to take common developer needs and
> practices in account.
>
> Today devs rely on a whole set of CSS properties which are stable enough
> for production use yet unavailable unprefixed in most deployed
> implementations.
>
> 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.

I'm suggesting that in general we avoid considering a prefixed 
implementation sufficient 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 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.

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

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

>> In general I don't like subsetting specs that
>> aren't using the living standard model of HTML5.
>
> I'm afraid there's a bunch of cases where we'll have to. But these might
> fall under the living standard model. Is there a list of which specs do
> somewhere? Notably, are the specs which have been recently moved out of
> the HTML5 spec and into WebApps part of the LS model?

Well officially W3C doesn't believe in Living Standards yet, and WHATWG 
hasn't moved (many) specs out into seperate documents.

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

Received on Saturday, 14 April 2012 21:47:28 UTC