W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2012

Re: [css3-transitions] [css3-animations] API for testing transitions and animations

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 14 Feb 2012 13:26:34 -0500
Message-ID: <4F3AA75A.7020700@mit.edu>
To: Aryeh Gregor <ayg@aryeh.name>
CC: public-css-testsuite@w3.org
On 2/14/12 1:11 PM, Aryeh Gregor wrote:
> On Tue, Feb 14, 2012 at 12:46 PM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>> 1)  It's possible for a regular web page to observe whether some aspects of
>> transition/animation behavior (say computed CSS values as functions of time)
>> are correct right now.  You could write tests to do such checking; they'd
>> just have to be written _very_ carefully if you want to avoid false
>> positives and false negatives.  For internal regression test suites, ease of
>> writing reliable tests is important, hence APIs to make it easier.
> What are examples of how this might work?

Say you have a transition from "width: 100px" to "width: 200px" that's 
supposed to take 1s.  When you do whatever you think will trigger the 
transition you start a 500ms timer.  When that timer fires, you examine 
the width of the element.  It should be 150px, to some tolerance.

If desired, random error can be reduced somewhat by doing this whole 
operation multiple times.

The question is what the tolerance should be.  And that depends on what 
the random and systematic errors involved are, what their typical sizes 
are, and which of them are allowed per spec.

>> 2)  It's possible for a human observer to detect broken aspects of
>> transition/animation behavior even if the page is seeing the right computed
>> styles (e.g. think a browser implementation that updates the styles on
>> demand but doesn't advance the timeline normally).   Of course depending on
>> an API for detecting this is silly, since the implementation is purposefully
>> lying to the script, basically.  But we do somewhat care about not allowing
>> such implementations to be considered conformant....
> Would this be resolved by allowing animated reftests?

Possibly, yes.  The ideal animated reftest for layout would be one that 
animates things on top of each other, with the thing on top green and 
the thing on bottom red, and asserts that no red is ever visible.  That 
means no need for the user to do anything other than look.

Obviously for colors that doesn't work, unless you use SVG to somehow 
composite things together and use feColorMatrix to map differences to 
something noticeable.

>> Sure, especially if they change at different wrong rates for different
>> animations, right?
> What's an example of how this might happen?

Say you have this sort of markup:

   <div style="width: 100px; background: red; color: white;
               vertical-align: bottom">
     <div id="one" style="display: inline-block; overflow: hidden;
                          width: 50px; background: green">
     <div id="two" style="display: inline-block; overflow: hidden;
                          width: 50px; background: green">
       More text

Then you transition #one to a width of 0 while transitioning #two to a 
with of 100px, using transition functions that should ensure that the 
sum of the two widths is 100px.  If the two elements are not 
transitioned at the same rate, you will either see slivers of red or the 
second inline-block will sometimes wrap to a second line.  The latter 
would obviously be considered as breaking the page, I think.

Received on Tuesday, 14 February 2012 18:27:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:24 UTC