Re: Dropping Prefixes Early on Transforms/Transitions/Animations

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?

Received on Tuesday, 21 February 2012 14:47:52 UTC