- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 16 Feb 2012 12:38:31 -0500
- To: Sylvain Galineau <sylvaing@microsoft.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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