- From: Florian Rivoal <florianr@opera.com>
- Date: Sat, 05 May 2012 00:04:54 +0200
- To: www-style@w3.org
On Fri, 04 May 2012 20:42:01 +0200, Dirk Pranke <dpranke@chromium.org> wrote: > On Fri, May 4, 2012 at 11:37 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> On 5/4/12 2:33 PM, Dirk Pranke wrote: >>> >>> On Fri, May 4, 2012 at 11:14 AM, Alan Stearns<stearns@adobe.com> >>> wrote: >>>> >>>> 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. >>> >>> >>> Isn't this essentially what the current process is supposed to be? >> >> >> The current process has a much higher bar for unprefixing than "Working >> group agreed to work on this spec". A bar that allows a draft to be >> worked >> on for years with multiple nearly-interoperable implementations in the >> market, before prefixes can start being removed. >> > > Sorry, I totally missed that last clause :( Right, that's a big > difference from CR. To be clear, though, this is still quite different > from what Florian is proposing ... It is, and I still prefer what I said. Under this variant, if the lag between release and the start of the standardization is long, there is a risk that the prefixed property (which isn't aliased yet) will be advertised and catch on, bring is us back to a scenario not entierly unlike what we have today with the excesses of -webkit- prefixing. Beside, as I said in another mail[1], even if half baked feature are shipped unprefixed and gets somewhat popular, we still have plenty of room to fix them as long as we are aware of the compatibility implications, as unprefixed doesn't mean frozen anymore. [1] http://lists.w3.org/Archives/Public/www-style/2012May/0147.html
Received on Friday, 4 May 2012 22:00:08 UTC