Re: Dropping Prefixes Early on Transforms/Transitions/Animations

On 16 Feb 2012, at 13:12, Sylvain Galineau wrote:

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

Have you filed the bugs with the other engines as well, or only Gecko?

Can we get some commitment from the various engine teams to have their QA teams look over the issues to see if there is any interop issues, and fix the low hanging fruit? That alone would get us a step closer to being able to move the 2D transforms spec forward at least.

I'm pretty sure each browser vendor has their own tests when implementing the specs in question. If we can get some commitment from those vendors to release their tests, if they haven't already, then that would give us another stride. I suspect they're also written in a way that can be automated (maybe not in a way that can be used with another vendor's automation tools though).

Maybe we can get some help from the community to go through tests if they can't be automated right away? I understand there has been tension with vendors sharing their tests, or at least the cross-browser results of those tests in the past, but we're at a time when it doesn't benefit anyone if we don't do as much as we can to push things forward as fast as we can. 


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

If there is some discomfort about some of the specs that we want to push ASAP, can we not at least agree on the specs we do feel comfortable with, and deal with the others separately rather than one whole? I guess 2D and 3D will be in one spec so that makes things difficult. Is there similar discomfort with transitions and animations or only 3D transforms? What are we all comfortable pushing ASAP?


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

How do we start  collect and analyse hard evidence ASAP, apart from pushing to get existing test cases out in the public faster?

Do we have a list of current issues we can go through together that we can decide if they cause interop problems if the prefixes are removed?

For spec issues, I couldn't find any open issues on TTA:

http://www.w3.org/Style/CSS/Tracker/issues/open?sort=product

And only one raised:

http://www.w3.org/Style/CSS/Tracker/issues/83

Am I looking in the wrong place? (Sorry, I'm new on the group). The issue above mentions "various issues" that the editor needs to split out. That was in 2008. Was that ever done? If not can we start doing that? This task seems somewhat related (from 2010) http://www.w3.org/Style/CSS/Tracker/actions/214

There is a small list of tasks in that list related to transitions, but I'm not sure if they've just not had their status changed?


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

No you're not. Getting out the other tests if they haven't already is critical if we want to move quickly.
> 
>> 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. 

This is less of an issue for browsers that release quickly like Chrome and Firefox, providing there is a commitment there that they'll fix the issues that come up. I can imagine it'd be an issue for IE which releases more seldom, but if we do things correctly we'll be done before IE11 comes out anyway ;) I was going to say IE10 but who knows how soon that will be out. Would it be a catastrophe if  the browsers that ship fast remove the prefixes and the browsers that release slower (IE and Safari) keep them until they're more comfortable? 

I guess the working group can't tell the browsers what to do, so Chrome, Opera and Firefox could just drop them anyway if they really wanted to.


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

Rather than requiring a full spec to reach CR, can't we just agree on a property by property basis what is ready to drop prefixes?

Are there any things we can get a move on doing now to lay the ground work for whatever decision we agree to regarding the two options up to vote? If we do those in parallel with debating which direction to take, we'll at least make some progress rather than stalling.

> 
>> 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 Friday, 17 February 2012 01:42:13 UTC