Re: Dropping Prefixes Early on Transforms/Transitions/Animations

On Wed, Feb 15, 2012 at 7:58 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
> 2. We are confident in our implementations but the specs are way behind; in that case,
> I asked that we at least attempt to establish the basis of our implementation confidence
> beyond anecdotal evidence that basic transform effects - e.g. animated rotations on
> :hover - and other demo pages appear to work the same 'everywhere'.

http://hg.csswg.org/test/file/tip/contributors/aryehgregor/incoming/

See the files 2d-transforms.html, 3d-transforms.html, and viewer.html.
 For versions directly runnable in your browser of choice, you can try

http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/

although I don't guarantee it will be stable (it's my scratch space
that I use before committing).  Looking at 2d-transforms.html in IE10
Developer Preview, a mozilla-central build from a few hours ago with
some pending patches applied, Chrome 18 dev, and Opera Next 12.00
alpha, I find:

IE: 5202 pass, 178 fail
Firefox: 5377 pass, 3 fail
Chrome: 5020 pass, 360 fail
Opera: 4377 pass, 1003 fail

(In case anyone raises eyebrows at Firefox's high pass rate: it's
because I've been filing bugs as I find them, and in some cases fixing
them.  Firefox 10.0.1 gets 2366 pass, 3014 fail.  I've reviewed all
the failures in the three major engines and am fairly confident that
the tests are correct in all cases where any browser fails.)

If you look at the substance of the failures, you'll see it's due to
just a few bugs per browser.  For instance, a majority of IE's
failures are because for the purposes of
getComputedStyle().transformOrigin, it evaluates percentages relative
to the content box instead of the border box (which contradicts not
only the spec, but its own rendering).  Firefox before nightlies of a
few days ago failed thousands of tests because it added "px" to
getComputedStyle(), so it failed every single test that checked
computed style.  Reftests demonstrate comparable interoperability in
most cases.

Now, these tests are not reviewed, and in some cases they contradict
the spec where I believe the spec to be wrong, and in some cases they
make assumptions where the spec is ambiguous, and they don't test
transitions or animations, and the 3D test pass rates are
significantly worse.  But I hope you'll agree that they qualify as
considerably more than anecdotal evidence that interop is pretty good.


That said, your argument seems to be that we can't allow unprefixing
until we have a good test suite.  This is great as long as people
actually bother to write test suites.  It took me about a month and a
half to write these tests, including time to isolate and file all the
Firefox bugs and fix many of them.  They could have been written a
year ago and results would have been pretty similar for 2D transforms,
as far as I'm aware.  It strikes me as problematic to require that
properties remain prefixed indefinitely unless someone is willing to
step up and write a good test suite -- there's no guarantee that
anyone will do so in a timely fashion.

Nor do I see why it's necessary.  HTML has gotten some extremely
successful new features in the last few years (such as canvas and
video) unprefixed from the start with no test suite to speak of.  The
worst case is that browsers aren't interoperable, bugs get reported,
they align, and the spec eventually gets updated to match.  This is
bad, but it's far from obvious that it's any worse than requiring
authors to specify the same exact property declaration five times
over.

Yes, authors expect that for unprefixed properties they can use the
same syntax and it will have the same effect.  They expect that for
prefixed properties too, which is why they just copy and paste the
same declaration.  There's nothing to be gained from requiring them to
do this.

But I'm not going to bother rehashing this issue yet again.  I have
better things to do than argue about process, such as writing more
tests and fixing Gecko bugs.  If it were up to me, I'd say the parties
in favor of unprefixing should ignore CSSWG policy and unprefix
features whenever they feel they're stable regardless of the formal
spec maturity level.  I'm on the record as not thinking spec maturity
levels are useful anyway, and everything should just be ED forever,
like the WHATWG's HTML spec.  But it's not up to me, so I really don't
see any value in arguing about it.

Received on Thursday, 16 February 2012 17:39:44 UTC