Re: Proposition to change the prefixing policy

My feeling is that the points I cited below are mostly plausible reasons to delay CR, but not particularly good reasons to delay unprefixing, at least in my opinion. Once there is rough interoperability in practice, then continued persistence of prefixes is actively damaging, and the benefit of isolating experimental or proprietary properties is considerably lower. I realize that others may want to draw the tradeoffs differently. I just wanted to point out that the gap in practice between your proposed approach and mine is likely to be quite large. Consider the thought experiment of how these approaches might have applied to recent examples such as transforms, transitions, gradients, etc. 

Regards,
Maciej

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

> On Sun, May 6, 2012 at 12:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> I think the WG's bar for CR is quite a bit higher than my (admittedly vague) "roughly interoperable" condition. Even when rough interoperabilty is established, arguments like the following might delay taking even a tiny split-off spec to CR, and in some cases they are even valid:
> 
> The bar for full CR-exit-level interop is probably too high for this
> transition (though it would be interesting to see if it's a problem in
> practice, once early test-dev becomes more the norm).
> 
> 
>> - UAs might match but the spec doesn't match what they do so it needs to be rewritten.
> 
> Obviously, we can't take a spec like this to CR.  The only reason
> browsers have interop is lucky accidents or reverse-engineering.
> However, once you have some tests, it's easy to rewrite the spec to
> match the browsers.
> 
>> - UAs might match but we want to change the spec syntax entirely, because what is implemented so far is not as elegant as it could be.
> 
> This is an ever-present danger.  We've seen its bad effects in the
> recent past.  This is just something that we need to be vigilant about
> - it's nearly impossible to totally close the door against this
> without also producing some of "this shit totally blows, but everyone
> accidentally converged on it because it was an exciting topic".
> 
>> - We need some tests first.
> 
> That's the whole point.  ^_^
> 
>> - Some people objected to going to LC because their pet issue is not yet addressed.
> 
> Tantek's proposal makes this impossible, because the cut/transition is
> "automatic" - the only person who could stop progress like this is the
> editor themself, and the WG can fix that if it's paying attention.
> 
>> - We need a longer LC period because groups X, Y and Z may want to review.
> 
> Not a significant concern.  "Longer LC" typically just means an extra
> 2 weeks, 4 at the outside.  If this sort of addition is significant to
> our problems, then those problems are worse (and somewhat different)
> than we've been assuming.
> 
>> - We have to address all the LC comments before we can go to CR.
> 
> That's on purpose - if something is wrong with the spec, it needs to
> be fixed.  That said, with this sort of policy in place, it might be
> easier to reject some LC comments as "stuff's frozen", and avoid
> excessive debate over issues.
> 
>> - Splitting off this one property makes no sense because it's too tightly integrated with another property.
> 
> Yes, obviously this is a "feature-level" sort of thing, not an
> individual property-level thing.  You may be able to slice a single
> large "feature" into a smaller core feature and several extras, which
> can be promoted separately, but it makes no sense to promote an
> incomplete piece of something.  However, I think this is actually
> rarer than one might initially think - looking over several newish
> specs, I'm having a hard time coming up with many pairs of properties
> that can't go independently.
> 
>> - We don't have enough editing resources to maintain yet another split off spec.
> 
> This shouldn't generate a significant amount of editing work - it's
> just the cost of running an LC, which I can say from experience isn't
> very high.
> 
> ~TJ
>

Received on Sunday, 6 May 2012 21:45:04 UTC