Re: Proposition to change the prefixing policy

On Fri, May 4, 2012 at 10:20 PM, Florian Rivoal <florianr@opera.com> wrote:

> On Sat, 05 May 2012 06:08:11 +0200, Glenn Adams <glenn@skynav.com> wrote:
>
>  On Fri, May 4, 2012 at 10:26 AM, Florian Rivoal <florianr@opera.com>
>> wrote:
>>
>>  Warning: long mail. If you want to skip the rationale, and just want the
>>> technical proposal, jump down to "==== Proposal ===="
>>>
>>>
>> I believe the policy is correct and should be retained. The correct way to
>> fix the issue is by moving specs to CR more quickly.
>>
>
> Even if we could speed up work on trendy specs by prioritizing better,
> I don't think we can go down from several years to a few months at most,
> which would be needed if we don't want prefixed properties to creep up
> too much in real content.
>

I would venture to assert that there's a direct correlation between the
number of uses of a prefixed property and the time it takes the WG to move
a document from FPWD to CR (at which point it can be unprefixed by the
current rules).

Accordingly, we need to find ways to accelerate the process of reaching CR.
Some ways to do this:

   - reduce the bar for transition to CR; after all, CR is technically the
   time in the process where implementation is supposed to get underway, i.e.,
   "call for implementations"; the WG should not wait for CR because some
   features are not fully worked out or because some technical comment is not
   fully resolved, or should be willing to mark more features at risk or
   remove them to v.next more quickly; an acceptable DoC response on a LC
   comment should be "WONTFIX" or "LATER";
   - the WG chairs should be more willing to overrule objections in order
   to quell unresolvable or stuck conflicts; it is perfectly acceptable to
   respond to an objection with "UNABLE TO RESOLVE", and bump that objection
   to a higher level for W3C team resolution;
   - establish a general rule for maximum duration to move from FPWD to CR,
   which, in case of failure to do so, the work is withdrawn or restarted
   under the next version (skipping a version/level);

How do you think authors should use prefixes? Not at all in production
> content? Include the unprefixed property preventively alongside the
> prefixed ones, or not? Include the prefixes only of browsers they have
> tested, or all browsers that currently have the feature, or all
> browsers, even the ones that don't currently have the feature?


any author who uses a prefixed property should be prepared to accept the
consequences of random changes to any UA that supports it at some point in
time; if they don't, that's their problem; if they don't like it, that's
tough...

authors would be better off to use shims/libs that can accommodate such
changes more rapidly, e.g., modernizr