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

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

From: Aryeh Gregor <ayg@aryeh.name>
Date: Tue, 14 Feb 2012 13:56:50 -0500
Message-ID: <CAKA+AxkMP3wEV9vJ8CY0yaxGSboLquwpOYKu2WHx2KwD+2ZBrQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-css-testsuite@w3.org
On Tue, Feb 14, 2012 at 1:26 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

If there are tight guarantees in practice on when the timer fires, we
should be able to spec those guarantees and write reasonably reliable
tests based on them.

If there aren't tight guarantees in practice, and the timer will often
decide to fire whenever it feels like it in real browsers, then pages
can't depend on the behavior.

If there aren't tight guarantees in practice, but pages depend on the
behavior anyway and just fail randomly, then we should institute
tighter guarantees, in which case see first paragraph.

In any event, we should be able to test this directly, not with a new API.

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

Or you can have it flip back and forth between the two pages every few
tens of milliseconds.  Then it will flicker if there are any
differences.  This would work best with animations that repeat
indefinitely, of course.

> 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">
>      Text
>    </div>
>    <div id="two" style="display: inline-block; overflow: hidden;
>                         width: 50px; background: green">
>      More text
>    </div>
>  </div>
>
> 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.

Sure.  That's also an example of something that animated reftests could handle.
Received on Tuesday, 14 February 2012 18:57:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 February 2012 18:57:51 GMT