Re: Proposition to change the prefixing policy

On May 6, 2012, at 3:46 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, May 7, 2012 at 12:21 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>> Gut feeling is what is used to drive unprefixed implementation of HTML elements and attributes, JS-exposed Web APIs, and DOM event names. That's largely because there is no formal policy at all for unprefixing those things. Do you believe that the gut feeling approach has been actively harmful in those cases? If so, can you give an example of the kinds of bad results you are worried about?
>> 
>> I'm asking in part because I feel that the vague prefixing rules that apply in other Web standards domains are a little bit too vague, but I can't think of examples of specific harm.
>> 
>> I understand and sympathize with your desire for an objective standard. However, in my experience, fully specified formal rules (including ones I've created myself) can have significant downsides. Formal rules can create perverse incentives and opportunities for gaming the system. Exercising subjective judgment is harder to do, but also harder to game.
> 
> That "gut feeling" only works because people are doing ad hoc testing
> to establish interop (as an input to the "are we stable yet?"
> question).  If there's testing going on anyway, I don't see the harm
> in making it explicit, so we have the start of a test-suite already
> completed.

I think your argument here may be affected by an anchoring effect. Given the current CSS prefix policy, it is easy to think of strict rules about prefixing/unprefixing are the norm. But every formal process has an intrinsic cost. So the correct baseline to compare to is no restrictions. The rational way to evaluate a rule is to disregard anchoring and apply a consequentialist analysis. Any additional rule or process should be justified in terms of having a net benefit compared to not having the rule, not on just the standard of "don't see the harm". 

I believe my proposal has a net benefit over no restrictions; it prevents single-vendor extensions from stomping on the common namespace without review, and it reduces the odds of locking in the bugs and quirks of the first implementation of any given property.

I think the net benefit of adding a test suite requirement (specifically not only creating one but having two implementations pass it) before unprefixing is not established. The reason I mentioned that "gut feeling" seems viable in other groups is to test what the concrete benefits might be. If an extra requirement to create and pass a test suite had a benefit, then we should be able to observe the harm of not doing it before unprefixing in other groups. Can you identify any such harm, or missed opportunities for additional benefits?

Regards,
Maciej

Received on Monday, 7 May 2012 16:52:12 UTC