Re: Proposition to change the prefixing policy

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

> This is approximately what our process is *already* supposed to be,

The current process for _entering_ CR does not involve interoperable 
implementations already existing....

As a general point, I believe the right way to think about anything we 
do here is in terms of incentives.

For example, the current setup, if we ignore altruistic and strategic 
considerations, mostly incentivizes UA vendors who want to get ahead in 
the market to implement behind a prefix, advertise their prefixed 
version to developers, and not push too hard for standardization or to 
actively block it.  It incentivizes UA vendors who want to counter such 
moves to try to push specs to CR faster.

Tantek's proposed setup incentivizes vendors who want get ahead in the 
market to implement prefixed, advertise the prefixed property, and 
contribute as many tests as they can to the pre-CR test suite to delay 
CR entry and hence unprefixing.  It incentivizes those who want to 
counter such moves to push for entry to CR with a smaller test suite 
(and in particular to do most of their test contribution after entry 
into CR).  This is definitely an improvement, though it still leaves the 
strong incentive to implement prefixed and then get developers to use 
the prefixed property.

My proposal earlier in this thread that prefixed properties not ship in 
final releases incentivizes UAs to not follow it.  If followed, it 
incentivizes UAs who want to get the functionality out to developers to 
push for a faster CR so they can actually ship the functionality, while 
making the job of those who want to keep the functionality of the web 
completely so it won't compete as well with proprietary stacks easier: 
they just need to block entry into CR.  This may be an untenable failure 
mode.

Maciej's proposal differs from Tantek's in the fact that the "roughly", 
by its very fuzziness, takes away the "write lots of tests for edge 
cases" strategy as a viable approach to delaying unprefixing.  On the 
one hand that means no UA vendor has an incentive to write such tests. 
On the other hand, it also means that there is slightly less incentive 
for a vendor to implement prefixed and advertise it, because others can 
clone the property and push the spec to CR without the vendor in 
question being able to block it, except insofar as they can affect the 
decision about whether implementations have "rough interoperability".

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?

-Boris

Received on Sunday, 6 May 2012 18:48:23 UTC