Re: Proposition to change the prefixing policy

On Fri, 04 May 2012 20:02:35 +0200, 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.
>
> And it doesn't take a feature being "massively popular" to poison the  
> well.  All it takes is one popular site using it for UAs to not be able  
> to change its behavior.

First, as Lea points out in another thread, this is mitigated by
the fact that they can take it to the WG as soon as their is a public
build, not a production build.

On top of that, if the feature fails to take off, we can still
tweak it to our hearts content.

If it does take off, either on many sites or on a few very popular
ones, we can still make some significant changes, even if we do have to
be careful about the type of change we are introducing.

It would constrain us a little bit, but we wouldn't be stuck. That could
prevent us from giving different semantics to the same syntax. But we could
very well change the syntax. Browsers could then support both syntaxes
until the massively popular site migrates to the updated version. Think
of how Opera and Firefox currently support both of these
background: -*-linear-gradient(left,blue,red);
background: -*-linear-gradient(to right,blue,red);

Besides, if it just one popular site, it is unlikely that they would
exercise all the corner cases of the new feature, so we would still
be free to change semantics without syntax regarding a lot of aspects.

Finally, I think Apple and Microsoft are the vendors who have stated
that they are unable to propose something for standardization until
they have shipped a implementation.

The consequences of Apple behaving that way under the current system
are already quite problematic. I don't need to highlight how painful
the current -webkit- situation is, and I don't think the consequences
of them behaving the same way under my proposed system would be worse.

First consider as I have said above that even if our ability to modify
a feature that is used in the wild is somewhat constrained, it is not
completely blocked. We just need to be aware of the compatibility
implications of our proposed changes.

On top of that, if we are discussing a feature that is seeing
significant use out there, we should be considering that anyway,
prefixes or not. Partly because unnecessary changes
in deployed features are unwelcome, but also because under
the current system, authors routinely use the unprefixed version
before it is available, so making incompatible changes can cause
breakage , which could make it impossible for browsers to switch
to the unprefixed version to avoid inflicting that breakage
on their users.

So, I don't think the constraints paused by the design of the first
to ship are unsurmountable, and anyway, they already affect us
under the current system.

  - Florian

Received on Friday, 4 May 2012 21:36:14 UTC