W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: Proposition to change the prefixing policy

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 6 May 2012 13:17:41 -0700
Message-ID: <CAAWBYDDdUOpjs_2QBAEaDSg0r8MnL5EfWzYPvMS4MiHm2kBK=Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
On Sun, May 6, 2012 at 11:47 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/6/12 9:21 AM, Tab Atkins Jr. wrote:
>> Tantek's proposal, which he brought to the group late in the last
>> Paris FtF, hits approximately the same sweet spot but with less
>> ambiguity - it's nearly a mechanical process.  As a reminder, his
>> proposal is that, at the moment anyone can prove two interop
>> implementations of a feature with a WG-approved testsuite, we cut that
>> feature into an LC->CR draft.
> I assume the idea is that a "basic" test suite would be used for this, and
> then a "full" test suite would be used to exit the CR?  Or at least that
> this is how it would work in practice, since that's the way the incentives
> work out?
> If so, I'd probably be fine with this approach.
> If we demand the level of test suite rigor we should be demanding for
> exiting CR out of an "enter CR" test suite, we might never enter CR (e.g. I
> don't believe any of gradients, transitions, transforms, would have two
> interop implementations on anything resembling a test suite that tries for
> good coverage).

Yes, it would be a testsuite that is approved by the WG to cover a
sufficiently wide range of activity.  It doesn't necessarily have to
plumb every single edge-case, though, hell, early test-cases might
help with that sort of interop convergence.

It's basically Maciej's suggestion, just with some rigor applied to it.

[snip stuff about incentives]

Yup, that's an excellent summary.

> Can we do better than Tantek's or Maciej's proposal from an incentive point
> of view?  I'm not sure we can.  Maybe we should start with the incentives we
> actually want and reason back to the actual process that will produce
> them.... if there is one?

I'm not sure we can do too much better either. :/ We want to let
authors experiment with things in as realistic an environment as
possible, but we don't want them to bake prefixes into the public web.
 We want to encourage unprefixing fast, but we don't want vendors to
fast-track their shit without getting adequate review.

These are mutually contradictory.  History shows that we've been too
far out on the "late unprefixing" side of the second incentive axis.
We can pull it back, or we can somehow fix the first incentive axis so
that our bias on the second doesn't hurt us so bad.

Tantek's proposal should help in the second axis.

Received on Sunday, 6 May 2012 20:18:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC