RE: Dropping Prefixes Early on Transforms/Transitions/Animations


[Aryeh Gregor:]
> 
> 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

That's actionable evidence that 2D is indeed in good shape. I think we
should all review this.

> 
> (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.

It does. Though my discomfort included 3D as the current plan is to push
both. 

> 
> 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.  

Of course. My argument is that authors have expectations from unprefixed
features; if we're going to go out and break our own rules so fast after
a meeting as controversial and visible as last week's, I think we owe
 the community some hard evidence that our actions are warranted. I'm
not comfortable with just asking the world to trust me because it'll 
all work out in the end. I'd rather be able to say: "We can do this now,
and this set of tests is enough to prove it". 

> 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.

I think it'd be more problematic to let browsers drop prefixes without any
concrete evidence of interop. Believe me, I'm aware of how much work it is.
The people who wrote most of the CSS2.1 test suite are down the hall.

> 
> 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.  

No published test suite could be more accurate. I doubt we're the 
only ones to write lots of internal testcases for our own work in 
that area.

> 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.

It depends on the bugs and for how long they'll stay in the wild. 
You could still end up with several declarations if one browser rejects
a value that another accepts. That's easy to handle if there is two but
the end result is imo worse. 

> 
> 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.  

This is not really about process. Some of us are OK with unprefixed
properties to have all kinds of bugs for months to come. If I shipped every
6 weeks and my users kept up, maybe I'd agree. But I still think it's not
author's job to QA our specs and establish a basic level of real-world interop
by filing bugs all over the place. I'd rather lose some velocity and start from
a higher quality level. I think the general argument is that some folks think
far too much velocity is lost to achieve that quality. And I think that is 
something we actually all agree on. But I don't think we need to think of
them as mutually exclusive. Maybe velocity and quality require smaller, more
focused specs, taking the success of a feature in existing content into
account, being aggressive about moving new ideas that haven't yet been 
implemented to a new level once some features in the module get traction etc.
We want to make it faster. But figuring out how is going to be no easier a 
consensus-building exercise than any other complicated feature with many 
moving parts. We'll keep at it. All input is welcome, however radical some 
members may find it.

> 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.

It's not up to only you, or only me. But from the above, I think it's up 
to you too. Thanks!

Received on Thursday, 16 February 2012 21:12:45 UTC