RE: Proposition to change the prefixing policy


[Lea Verou:]
> 
> On 5/5/12 16:18, Boris Zbarsky wrote:
> > If we're talking about previews, then it seems like the right solution
> > is to not ship prefixed stuff in final releases; just keep it in
> > previews.  Yes, this has come up before.  Getting everyone to agree on
> > this and stick to it is the hard part, given the benefits defecting
> > has.  And of course authors seem to be against this approach.
> >
> > -Boris
> >
> There are several issues with this:
> 1. It has been mentioned in this thread that it’s against company policy
> of several implementors.

Are we talking about implementors who will not submit a spec for a new
feature before they have released a public implementation for it? That 
is rather different from not putting code in a nightly/preview build if 
it won't make the very next upcoming release. But yes, in practice we all 
want our preview code to ship at some point and even without a hard policy 
it's much easier if 'some point' happens to be the next release! So that's 
how it's worked out in practice. And I think it's fair to assume we'd all
rather keep it that way.

> 2. It defies the entire advantage that prefixes were supposed to bring:
> Getting author input for in-development features. When the feature is
> present only in a preview (or in a stable build, but behind a switch), the
> volume of author feedback declines tremendously. I believe Alex Russell
> has specific statistics of how big a decline we’re talking about, but I
> recall it’s > 90%. This would result in specs being developed almost
> blindly, detached from the reality of author needs. Do we want that?
> 
Would love to see those numbers. I'd expect at least three factors to 
explain this:
1. How hard it is to get one's hands on preview/nightly builds and install them
2. The stability of these builds
3. The number of end users who run those builds.

Between Chrome's Dev channel and Mozilla's Aurora builds the bar for #1 has 
been substantially lowered. #2 has improved significantly as well, quite 
possibly as a result of #1.

#3 is of course the overwhelming factor though. Web developers will naturally 
focus most of their time on what they can deploy to the end-user. 
 
Last, these features are one of the ways browser releases compete with each
other. As a browser rep I obviously value this i.e. if the process was such 
that I were forced to give developers substantially fewer tools than they
ask for and that I can deliver then I'd strenuously argue for the process 
to change.

Received on Saturday, 5 May 2012 14:48:14 UTC