W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: Proposition to change the prefixing policy

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 6 May 2012 13:31:45 -0700
Message-ID: <CAAWBYDCjucD+YYQQrtXGn4harMD1+1KEsjthG+1gX1Lrt33PjQ@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
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.

Received on Sunday, 6 May 2012 20:32:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC