RE: Proposition to change the prefixing policy

[Maciej Stachowiak:]
> 
> 
> On May 4, 2012, at 11:14 AM, Alan Stearns <stearns@adobe.com> wrote:
> 
> > On 5/4/12 11:02 AM, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:
> >
> >> On 5/4/12 1:26 PM, Florian Rivoal wrote:
> >>> In the cases where implementations and real world usage are ahead of
> >>> the spec, then yes, it would limit the ability of the WG to make
> >>> incompatible changes. But this isn't necessarily bad.
> >>
> >> It can be quite bad.
> >>
> >> Several WG members have indicated on numerous occasions that as a
> >> matter of company policy they are unable to propose something for
> >> standardization until they have shipped a (prefixed, at the moment)
> >> implementation of it.  What this means with your proposal is that any
> >> ideas they have, no matter how half-baked, would have to be dumped
> >> out on the web without a prefix before they could even start to bring
> >> them to the working group.
> >
> > I do not think this would necessarily be the case. Experiments and
> > browser-specific features could still be added with a vendor prefix only.
> > We could mandate that the unprefixed version (aliased to the prefixed
> > version) could only come after the appropriate standards body had a
> > proposal in hand and agreed to work on it.
> 
> Here's another slightly more conservative version.
> 
> Properties can be shipped in unprefixed form once both of the following
> are true:
> (A) The appropriate standards group (most likely the CSS WG for CSS
> properties) has agreed to take up the relevant specification as a work
> item; AND
> (B) At least two independent roughly interoperable (though not necessarily
> identical in all edge cases) implementations are publicly available.
> 
> This would leave room for truly experimental work and proprietary
> extensions, and would avoid locking in syntactic quirks immediately, but
> would phase out prefixes much more quickly than the current approach of
> waiting for CR.
> 
If implementors also back up their unprefixed implementation at this stage
with testcases this could also help speed up the process. Additionally, I
think editors should make their best efforts to ensure spec changes are 
backward-compatible once this 2+ implementation phase begins. If a breaking 
change were deemed necessary by the WG, it should also be recorded in a spec 
appendix from that point on. I suspect it could be easier to reach REC and 
iterate to the next level if it were harder to make changes once implementations 
reach a usable stage. It could also make it harder to leave important items 
such as naming and interactions with other specs 'for later' though that may 
be optimistic.

Received on Saturday, 5 May 2012 22:41:15 UTC