Re: Ringmark is now open source

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.


We can immediately discard prefixes indicative of proprietary APIs (where
there's no intention from the implementor to standardize). These obviously
don't belong in a standard.

Looking at other prefixes, we can see that they roughly go through the
following lifecycle.

1) At first, prefixes are indicative of experimental implementations.
There's possibly early related spec work going on (an editor's draft or
similar). There's usually a single implementation or sometimes multiple,
competing implementations with slightly different syntaxes. There are
demos of the feature. It's starting to get used in production by very
early adopters. This is obviously too experimental to include in a spec.

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

3) Once the spec is finished, implementors start implementing unprefixed
versions of the feature.

4) Shortly thereafter implementors remove support for the prefixed version
(this is not respected in practice).


Coremob level 0 should be able to include specs currently at stage 2 (how
exactly we define stage 2 can be further refined) and add a non-normative
disclaimer for developers that they might need to prefix the property. E.g.


    User agents SHOULD support CSS 2D Transforms [CSS3-2D-TRANSFORMS].

    This is informative-only: Developers should be aware that some
implementation might only support a vendor-prefixed version of this spec
and are invited to code accordingly.

Coremob Level 1, on the contrary would explicitly prohibit this through a
global disclaimer E.g.:

    Prefixed implementations by themselves cannot claim conformance.

And specific changes to how the spec is referenced, e.g.:

    User agents MUST support CSS 2D Transforms [CSS3-2D-TRANSFORMS].

Regarding the test suite, I would argue that level 0 should allow prefixed
only version to still pass the tests and level 1 shouldn't. I believe this
is what developers will expect as in practice, one the feature is
available, and that's what counts the most.


>The Ring 0 document also curently calls for implementations of a number
>of things that are aiui still quite unstable e.g. flexbox. Could we loop
>in
>someone from the CSSWG to see which of the listed specs are considered
>mostly stable?

Yes, that would be super useful. Think you could look into this?

>Some more comments: "Implementors should pay special attention to" seems
>silly.

Agreed that section needs work.

>We should just 
>link to the testsuite.

Not sure what you mean by this.

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

>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. However, developers now expect quite a large chunk of ES5.1
to be available in implementations they target, notably JSON,
Function.proto.bind and array enumerables.

I've been struggling with how to express that in the spec today, so your
help is certainly welcomed.

>I also note that there is a MUST level requirement that is implicitly
>reduced to a SHOULD by the following text, and is untestable (about tel:,
>mms:, etc. URI shcemes).

Fixed here: https://github.com/coremob/level-0/commit/df3f70

--tobie

Received on Saturday, 14 April 2012 00:02:28 UTC