RE: Dropping Prefixes Early on Transforms/Transitions/Animations

[Simon Fraser:]
> 
> 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. 

Don't we have already have that risk today when authors "future-proof" their 
stylesheets by copy-pasting an unprefixed version of the current syntax? 

> As Sylvain keeps saying, it is not sufficient for just the syntax to be 
> stable; you have to have proven interoperability.

If two UAs implement a new property in a non-interoperable way - or if some 
subset of valid values don't interop well - then that is when you would fall 
back to the prefixed version. If the only way to achieve the desired rendering 
is engine targeting then that is where a vendor-prefixed mechanism is super 
useful vs. requiring everything to be specified n times even when it can be the
same thing.

> 
> 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.
> 
Yes, that is definitely the risk. But this only leads us back to CSS as it is 
practiced by authors: if you agree that a large-enough majority will include an 
unprefixed version of a new feature in their stylesheet because it's the 'best 
practice' then haven't we already lost the experimentation phase? At least 
when the feature is successful on the web? Fwiw IE never had a prefixed border-radius 
but we saw the feature light up nearly overnight in many pages courtesy of 
future-proofing. (Saved by authors doing it wrong!) And I can see how, in such 
a case, Aryeh and others can argue that anything that forces us to think very 
hard before we go 'fix success' is more a feature than a bug for the people who 
created all that content. Maybe going on a gradient syntax makeover - which I 
approved of at the time, by the way - when there are four broadly compatible 
implementations supporting a lot of content should be a very difficult call. 

But I do acknowledge that while 20/20 hindsight tells us this would have worked
well for border-radius or 2D transforms, the impact it would have had on other 
features is not so clear. As most of our work does fall somewhere between the
best/worst cases of border-radius stability and gradient redesign I'm not sure 
what general solutions we can derive from them. But it's a fair bet they'll 
remain 'business cases' for doing something, for proving the CSSWG does it wrong etc.

Received on Tuesday, 21 February 2012 22:20:53 UTC