Re: Dropping Prefixes Early on Transforms/Transitions/Animations

On Feb 21, 2012, at 6:47 am, Aryeh Gregor wrote:

> On Mon, Feb 20, 2012 at 5:44 PM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
>> Again, the scenario here is that what you want is not 'more or less interoperable'.
>> There is a problem you need to work around.
> 
> Right -- but what about when it is?  If all I want to do is have a
> tabstrip at the top of the page where text is rotated 90 degrees, I'm
> pretty sure every browser would render that just fine since its first
> release of transforms.  Why should I have to write
> 
>  -ms-transform: rotate(90deg);
>  -moz-transform: rotate(90deg);
>  -webkit-transform: rotate(90deg);
>  -o-transform: rotate(90deg);
>  transform: rotate(90deg);
> 
> in such a case?  Let me just write "transform: rotate(90deg)".  Then
> if, I don't know, Firefox treats rotations as being in the opposite
> direction, I can add "-moz-transform: rotate(-90deg)".  At least
> that's only two lines.  And when Gecko fixes the bug, maybe they'd
> decide to fix it only in the unprefixed version so as to preserve
> compatibility with such workarounds.  And when they decide they're
> compatible enough, they can drop support for the prefixed version.
> 
> But why require all five lines even in cases where the author tests
> and finds that browsers *are* interoperable?
> 
>> Well, that was exactly my point i.e. prefixes do help in that case. But maybe
>> your proposal here is the novel one in this old topic i.e. what if browser implement
>> new features both behind and without a prefix? Values that do interop will work
>> as-is unprefixed. Those that don't and other changes can be targeted using the
>> UA-specific prefixed property i.e. the prefix property is a fallback if and when
>> a browser needs a targeted workaround instead of being the only available way to
>> use the feature.
> 
> Sure.  Let's focus on that.  (Which is why I didn't respond to the
> rest of your post -- you gave some excellent rebuttals to other things
> I said, but better not to get distracted.)
> 
> Does anyone have objections to that idea?  Once syntax is basically
> stable, UAs should support both prefixed and unprefixed versions.
> Authors should use unprefixed versions.  If they find a bug they need
> to work around, they can use the prefixed version for that one
> occurrence, overriding the unprefixed version.  When UAs are confident
> enough in their unprefixed implementation that they don't think anyone
> will need to work around their bugs, they can drop support for the
> prefixed property if they want.  How does that sound?

I object, on the basis that if browsers support unprefixed properties too early,
it results in lock-in in potentially incorrect or suboptimal behavior before the
CSS WG can have a chance to fix it. As Sylvain keeps saying, it is not sufficient
for just the syntax to be stable; you have to have proven interoperability.

WIth transforms we just happened to have a dominant implementation in WebKit
that gets things mostly right and matches the spec. But things are not always so stable;
don't forget that we changed the rotation angle in gradients after browsers had
shipped support for the old direction (luckily, in the prefixed linear-gradient function).

Or, imagine that our perspective/flattening discussion had come out a different
way, and you were able to persuade me that transform-style was unnecessary.
If we'd already shipped unprefixed, we would not have been able to every change that.

Premature dropping of prefixes leads to early lock-in, which is not a good way
to develop standards. The whole point of prefixes is to allow UA experimentation,
and for authors to provide feedback. If we prematurely drop prefixes, we throw away
that experimentation phase.

Simon

Received on Tuesday, 21 February 2012 16:35:45 UTC