Re: Proposition to change the prefixing policy

On Sat, 05 May 2012 01:28:37 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/4/12 6:04 PM, Florian Rivoal wrote:
>> we still have plenty of room to fix
>> them as long as we are aware of the compatibility implications
>
> That's a _huge_ caveat.
>
> In my experience no one is aware of compatibility implications until  
> typically weeks to months after shipping some change in a final release.  
>   That's when you start getting all the reports about all the things  
> that broke....
>
> Witness the fact that some UAs aren't willing to change the behavior of  
> its prefixed properties to match the behavior of the unprefixed versions  
> if they don't happen to coincide, even if the changes are small.
>
> What makes you think they would be happier changing the behavior of  
> unprefixed properties?

There were a lot of things that were not interoperable in CSS 2 / 2.1,
existed unprefixed, and got fixed overtime, demonstrating that
UAs are perfectly willing to change the behavior of their unprefixed
properties when the benefits are clear, even if it break some sites
in the process.

On the other hand, there is less incentive to change the behavior of
prefixed properties. There is no interoperability issue, since the
prefix is unique to each vendor, and the deficiencies in behavior
that restrict what could ideally be done with this feature if it was
better will be addressed through the unprefixed property. So why bother?

The problem is that since the what the unprefixed property is supposed to
do can currently evolve without it being tried out in the wild, because
the prefixed properties are not following it, we might not notice that
we accidentally broke compatibility until we're past CR and vendors
notice the breakage when trying to drop prefixes. When that happens,
we're stuck with prefixed properties that will never be removed,
authors that know it and write content for them even when they
could write for unprefixed, careless evangelists who keep
advertising the prefixed property when it is not longer needed, etc.

If we did things the way I suggest, we would notice faster
(implementation time, rather than unprefixing time) when a change
to the spec "breaks the web", and would therefore get the opportunity
early on to discuss whether it is worth breaking the web for, or
if we should revisit our decision.

  - Florian

Received on Monday, 7 May 2012 13:25:45 UTC